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PROTOCOL FOR MANAGING AND METHOD OF VERIFYING AND OF 
CONVERTING A DOWNLOADED PROGRAM FRAGMENT. AND 
COKRESPONDINQ SYSTEMS 

The invention relates to a protocol for roajoag- 
ing, a method of verifying saik a method of transforming 
a downloaded program fragment and the corresponding 
Bystems, more particularly intended for on-board data- 
proceseing systems having few reeources available in 
terms of memory and of - conputing power. 

In a general way, by reference to figure la, it 
is reiterated that on-board data-processing systems 10 
include a microprocessor 11, a permanent memory, such 
as a non-writable memory 12 containing the code of the 
executable program, and a rewritable, nonvolatile, per- 
manent memory 15 of EEPROM type containing the data 
stored in the system, a volatile, random-access memory 
14 in which the program stores its intermediate results 
while it is executing, and input/outjput devices 15 al- 
lowing the system to interact with its environment. In 
the case in which the on-board data-processing system 
consists of a microprocessor card, of the bank-card 
type, the input/output device 15 consists of a serial 
link allowing the card to conHmmicate with a terminal , 
such as a card-reader terminal. 

Ill conventional on-board data-processing sys- 
tems, the code of the program" executed by the system is 
fixed during construction of the system, or, at the 
latest, when the latter Is customized before delivery 
to the final user. 

More sophisticated on-board data-processing sys- 
tems have, however, been implemented, these systems be- 
ing reprogrammable, such as microprocessor cards of the 
JavaCard type, for exampl . with respect to the preced- 
ing types, these reprogrammable systems add the possi- 
bility of enhancing the program after the system has 
been put into seivice, via an operation of downloading 
program fragments. Th s fragments of programs, widely 
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designated by "applets', will be designated applets, or 
program fragments indiscriminately in the present d - 
scription. For a more detailed description of JavaCard 
systems, reference could usefully be made to the docu- 
5 mentation published by the company SDN MTCROSYSTEMS 
INC., and in particular to the electronically available 
documentation, JavaCard technblogy chapter, on the www 
(fItorJd Wide web) site 

http://java.sun.com/products/javacard/index.html, June 
10 1999. 

figure lb illustrates the architecture of such a 
reprogrammable on-board data-processing system. This 
architecture is similar to that of a conventional on- 
board system, with the difference that the reprogramma- 
ble on-board system can moreover receive applets by way 
of one of its input /output devices, then store them in 
its permanent memozy 13 f rom . which they can then be 
executed as a supplement to the main program. 

For reasons of portability between different on- 
board data-processing systems, applets are presented in 
the foiTO of code, for a standard virtual machine, miis 
code is not directly executable by the microprocessor 
11, but it has to be interpreted in software tezms by a 
virtual machine 16, which consists of a program resi- 
dent in a non-writable pemianent memofy 12. in the 
abovementioned example pf JavaCard cards, the virtual 
machine used is a subset of the Java virtual machine. 
For a description of . the specifications relating to the 
Java virtual machine • and of the virtual machine' used, 
reference could usefully be made to the work published 
by Tim LINdhOLM and Frank YELLIN, entitled "The Java 
Virtual Machine Specification-. Addison-Weeley 1996, 
and to the documentation published by the company SUN 
MICROSYSTEMS INC. "JavaCard 2.1 Virtual Machine Speci- 
fication-, documentation availabl electronically on 
the www site http://java.sun.com/products/javacard/ 
JCVMSpec.pdf, March 1999. 
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The operation o£ dowaloading apple;bs onto an on- 
board data-rprocessing system in service pos s consider- 
able security problems. An applet which is involxmtar- 
ily, or even deliberately, badly written may incor- 
rectly roodiJ^ data present on the system, prevent tiie 
main program from executing correctly or at the right 
time, or else modify other applets downloaded previ- 
ously, making them unusable or harmful. 

An applet written by a coniputer hacker may also 
divulge confidential information stored in the system, 
information such as the access code in the case of a 
bank card, for example. At the present time, tliree so- 
lutions have been proposed with a view to remedying the 
problem of security of applets. 

A first solution conBists in using cryptographic 
signatures, so as to accept only applets originating 
from timsted bodies ox persons . 

In the abovementioned exanple of a bank card, 
only the applets bearing the cryptographic signature of 
the bank having issued the card are accepted and exe- 
cuted by the card, any other unsigned applet being re- 
jected in the course of the downloading operation. An 
ill-intentioned user of the card, not having available 
encryption, keys from the bank, will therefore be- inca- 
pable of executing an unsigned and dangerous applet on 
the card. 

liiis first solution Is well adapted to the case 
where all the applets originate from the same single 
source, the bank in the abovementioned exan5)le. This 
solution is difficult to apply in the case in which the- 
applets originate from several sources, such as, in the 
exanple of a bank card, the manufacturer of the card, 
the bank, the bodies managing, services by bank card, 
thelarg? commercial distribution organizations offer- 
ing clientele loyalty programe and proposing, legiti- 
mately, to download specific applets onto the card. The 
sharing and th holding among these various economic 
participants of the encryption keys necessary for the 
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electronic signature of th . applets pose major techni- 
cal « economic and legal problems. 

A. s cond solution consists in carrying out dy- 
namic checkB on access and on typing . during the ex cur-' 
5 tion of the applets. 

In this solution, the virtual machine carries 
out a certain number of checks, during the execution of 
the applets, such as: 

check of access to the memory: upon each 
; 10 . read or write in a memory area, the virtual, machine 
verifies the right df ; access the applet to the cor- 
jresponding data; 

dynamic, verification of the data types: upon 
each instruction from the applet, the virtual machine 
15 verifies that the cbn«traints on the data .types are 
satisfied. By way of. exanple, the virtual machine may 
have special handling for data such as valid memory ad- 
dresses, and prevent the applet generating invalid mem- 
ory addresses by way of integer /address conversions or 
20 arithmetic operations on the addresses; 

detection of stack overflows and of illegal 
accesses to the execution stack of the virtual machine, 
which, under certain conditions, are likely to disturb 
the operation thereof, to the point of circumventing 
25 the preceding check mechanisms. 

This second solution allows execution of a wide 
range of applets under satisfactory security condi- 
tions. However, it features the drawback of a consider- 
able slowing of the execution, caused by the range of 
30 dynamic verifications.. In order to obtain- a' reduction 
in this slowing, some of these verifications can be 
taken charge of by the microprocessor itself, at the 
cost, however, of an increase in the complexity thereof 
and thus of the cost price of the on-^ board system. Such 
35 verifications furthermore increase th requirements for 
random-access and permanent memory of th system, by 
reason of the additional type information which it is 
jiecessary to associate with th data handled* 
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A third solution consists in carrying out a 
static verification of the code of the applet during 
the downloading. 

In this solution, this static verification siniu- 
lates the execution of the applet at the level of the 
data types and establishes, once and for all, that the 
code of the applet conplies with the rule of data types 
and of access control inposed by the virtual machine 
and does not cause a stack overflow. If this static 
verification is successful, the applet can then be exe- 
cuted without it being necessary dynaniically to verify 
that this rule is ccaiplied with. In the event that the 
static verification process fails, the on-board system* 
rejects the 'applet' and does not allow its subsequent 
executiOT. For a more detailed description of the 
abovementioned third solution, reference could usefully 
be TOade to the work published by Tim LINDHOLM and Prank 
YELLIN quoted above, to the article . published by James 
A. . GOSLING entitled "Java Intermediate Byte Codes", 
proceedings of the ACM SIGPLAN, workshop on Intermedi- 
ate Representations (IR'95), pages 111-118, January 
1S95, and to the US patent 5,748,964 granted on 
05/05/1998. 

Compared witli the second solution, the third so- 
lution presents the advantage of a much more rapid exe- 
cution of the applets, since the virtual machine does 
not carry out any verification during execution, 

The third solution, however, features the draw- * 
back of a process of static verification of the code 
which is conplex and eaqpensive, both in terms of- size 
of code necessary to conduct this process and in terms 
of size of random-access memory necessary to contain 
the intermediate results of the verification, and- in 
terms of conputation time. By way of illustrative exam- 
ple, the code verification integrated into the Java JDK 
system marketed by SDN MICROSYSTEMS r presents about 50 
kbytes of machine code, and its consuaption in terms of 
random-access memory is proportional to {Tp + Tr> x Nb, 
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where Tp designates the xnaxlmom stack space, Tr desig- 
nates the xnaxlmum number of registers and Kb designates 
the maxiimam number of branching targets used by a sub- 
program, also widely designated by method, of the ap- 
5 plet. These memory requirements greatly exceeded the 
capacities of the resources of the majority of the pre- 
sent-day on-board data-processing systems, especially 
of commercially available microprocessor cards. 

Several variants of the third solution have been 

10 proposed, in which the writer of the applet sends to 
the verifier, in addition to the code of the applet, a 
certain amount of specific supplementary information 
such as precalculated data types or preeetablished 
proof of correct data typing* For a more detailed de- 

15 scription of the corresponding operating modes, refer- 
ence could usefully be made to the articles published 
by Eva ROSE and Kristoffer H0GSBRO ROSE, • Lightweight 
Bytecode Verification", proceedings of the Workshop 
Formal Underspinning of .Java, October 1998, and by 

20 George C. NECDIA, • Proof -Carrying Code', Proceedings of 
. the 24th ACM SympoBium Principles of Programming Lan-^ 
guagee, pages 106-119, respectively. 

This supplementary information maXes it possible 
to verify the code more rapidly and slightly to reduce 

25 the size of the code of the verification program but 
does not make it' possible, however, to* reduce the re- 
quirements for random-access memory, or even increases 
them, very substantially, in the case of the correet- 
data-typing preestabli shed-proof information, • 

30 The object of the present invention is to remedy 

the abovementioned drawbacks of the prior art. 

In particular, one subject of the present inven- 
tion is the implementation of a protocol for managing a 
downloaded program fragment, or applet, allowing execu- 

35 tion of the latter by. an on-board data-processing sys- 
tem having few resources availabl , such as a micro- 
processor card. 
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Tuiother subject of the present invention is also 
the inplementation of a method of verifying a down- 
loaded program fragment, or applet, in vhich a process 
of static verification of the code of the applet is 
conducted when it is doMWiloaded, this process possibly 
being aligned, at least in its principle, with the 
third solution described above, but in which new veri- 
fication techniques . are introduced, so as to allow exe- 
cution of this verification within the limits of values 
of memory size and of conputation speed imposed by the 
microprocessor cards, and other low^power on-board data- 
processing systems. 

Another subject of the present invention is also 
the implementation of methods of transforming progr.aro 
fragments of conventional type obtained, for exaiqple, 
by the use of a Java compiler on standardised program 
fragments, or applets, satisfying, a priori, verifica-' 
tion criteria of the verification method which is the 
siabject of the invention, with a view to accelerating 
the process of verifying and executing them at the 
level of present-day microprocessor cards or on-board 
data«-proce66ing systems. 

Another subject of the present invention is, fi- 
nally, the production of on-board data-processing sys- 
tems allowing implementation of the abovementioned pro- 
tocol for managing and of the abovementioned method of 
verifying a downloaded program fragment as well as of 
data-processing systems allowing implementation of the 
methods of transforming conventional program fragments, 
or applets, into standardized program fragments, or ap- 
plets, as mentioned above. 

The protocol for managing a downloaded program 
fragment on a reprograirmvable on^board system, which is 
the subject of th present invention, applies espe- 
cially to a microprocessor card equipped with a rewri- 
table memory. The program fragment consists of an ob- 
ject code, a series of instz^ictions, executabl by the 
microprocessor of the on-board system by way of a vir- 
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tual machine equipp d with an execution stack and with 
aocal variables or registers manipulat d via these in- 
structions and making it possible to interpret this ob- 
ject code. The on-board system is interconnected to a 
5 terminal. 

It is noteworthy in that it consists at least, 
at the level of the on-board system, in detecting a 
command for downloading of the program fragment. On a 
positive response to the stage consisting in detecting 

10 a downloading ccmtmand, it further consists in reading 
the object code constituting the program fragment and 
in temporarily storing this object code in the rewri- 
table memory. The whole of the object code stored in 
memory is svibjected to a verification process, instruc- 

15 tion by instruction- The verification process consists 
at least in a stage of initializing the type stack and 
the table of register types representing the state of 
the virtual machine at the start of the execution of 
the tenporarily stored object code and in a succession 

20 of stages of verification, instruction by instruction, 
of the existence, for each current instruction, of a 
target, branching- ijistruction target, target of an ex- 
ception handler, and in a verification and an updating 
of the effect of the current instruction on the type 

25 stack and on the table of register types • In the event 
Of an unsuccessful verification of the object code, the 
protocol which is the subject, of the invention consistis 
in deleting the momentarily recorded, program fragment, 
when omitting to record the latter in the directory of 

30 available program fragments, and in sending an error 
code to the reader. 

• The method of verifying a program fragment down- 
loaded onto an on-board system, which is the subject of 
the invention, applies especially to a microprocessor 

35 card equipped with a rewritable memory. The program 
fragment consists of an object cod and includes at 
least one subprogram, a series of instructions, execu- 
table by the microprocessor of the on-board system by 
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way o£ a virtual machine eQuipped with an ex cution 
stack and with operand registers manipxilated l>y these 
instructions, and inaTcing it possible to interpret this 
object code. The on-board system is interconnected to a 
5 reader. 

It is noteworthy in that, following the detec- 
tion of a downloading comraand and the storage of the 
object code constituting the program fragment in the 
. rewritable memory, it consists, for each 3-ubprogram, in 

1.0 carrying out a stage of initializing the type stack and 
the table of register types by data representing the 
state of the virtual machine at the start o£ the execu- 
tion of the temporarily stored object cpdei in carrying 
out a verification of the teinporarily stored object 

15 code instruction by instruction, by discerning the ex- 
' istence, for each current instruction, of a branching- 
instruction target, of a target of an . exertion-handler 
call or of a target of a subroutine call, and in carry- 
\ ing out a verification and an updating of the effect of 

20 the current instruction on the data typ^s of the type 
stack and of the table of register types; on the basis 
of the existence of a branching- instruction target, of 
a target stibroutine call or of a target of an excep- 
tion-handler call. The verification is successful when 

25 the table of register types is not modified in the 
course of a verification of all the instructions, this 
verification process being ceorried out instruction by 
instruction until the table of register types is sta- 
ble, with no modification present. Otherwise the veri- 

30 fi cation process is interrupted. 

The method of transforming an object code of a 
program fragment into a standardized object code for 
this same program fragment, which is the subject of the 
present invention, applies to an object code of a pro- 
( 35 gram fragment in which the op rands of each instinjction 

belong to the data types manipulated by. this instruc- 
tion, the execution stack does not exhibit az^ overflow 
phenomenon and, for ach branching instruction, the 
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type of the variables of the stack at t±ds branching is 
the same as at the targets of this branching. The stan- 
' dardized object code obtained is such that the operands 

of each instruction belong to the data types inanipu- 
5 lated by this instruction, the execution stack does hot 
exhibit any overflow phenomenon and the execution stack 
is enqpty at each branching- target instruction. 

It is noteworthy in that it consists, for all 
the instructions of the object code, in annotating each 

10 current instruction with the data type of the execution 
stack before and after the execution of this instruc- 
tion, the annotation data being calculated by means of 
an analysis of the data stream relating to this in- 
struction, in detecting, within the instructions and 

IS within each curxent instruction, the existence of 
branchings for which the executicm stack is not empty, 
the detection operation being carried out on the basis 
of the annotation data of the type of stack variables 
< allocated to each current insti::uction. In the presence 

20 of a detection of a non-enjpty execution stack, it fur- 
ther consists in inserting instructions to transfer 
stack variablefs on either side of these branchings or 
of these branching targets in order to empty the con- 
tents of the execution stack into tengporary registers 

25 before this branching and to reestablish the execution 
stack from the teirporary registers after this branch- 
ing, and in not inserting any transfer instruction oth- 
erwise. 

This method thus makes it possible to obtain . a 
30 standardized object code for this same prpgram frag- 
ment, in which the execution stack is empty at each 
branching instruction and branching- target instruction, 
in the absence of any modification to the execution of 
the program fragment. 
( . 35 The method of transforming an object code of a 

program fragment into a standardized object code for 
this same program fragment, which is the subject of the 
present invention, applies, moreover, to an object code 



wo 01/14958 



- 11 - 



PCT/FROO/02349 



of a program fragment in which the operands of each in- 
' . struction belong to the data types inanipulated J?y this 

' instinaction, and a operand of given type written into a 

register by an instruction of this object cod is re- 
5 read from this same register by another instruction of 
this object code with the same given data type. The 
standardized object code obtained is such that the op- 
erands belong to the data types manipulated by this in- 
struction, one and the same data type being allocated 
10 to the same register throughout the standardized object 
code. 

•It is noteworthy in that it consists, for all 
the instructions of the object code, in annotating each 
current instruction with the data type of the registers 

15 before and after the execution of this instruction, the 
annotation data being calculated by means of an analy^ 
sis c£ the data stream relating to this instruction, 
and in carrying out a reallocation of the original reg- 
^ ( . isters eznployed with different types, by dividing these 

20 original registers into separate standardized regis- 
ters. One standardized register is allocated to each 
data * type used. Reupdating of the instructions which 
manipulate the operands which use the standardized reg- 
isters is carried cut. 

25 ^e protocol for managing a program fragment, 

the method of verifying a program fragment, the methods 
of transforming object code of program fragments into 
standardized object code and the corresponding systems, 
which are the subjects of the present invention, find 

30 an application in the development of reprogrammable on- 
board systems, such as microprocessor cards, especially 
in the Java environment. 

They will be better understood on reading the 
description and on perusing the drawings below, in 

35 which, other than figures la and lb relating to the 
prior art: 
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- Figure 2 represents a flew chart illustrat- 
ing the protocol for managing a program fragment down- 
loaded onto a reprogrammable on-board system. 

Figure 3a represents, by way of illuetra- 
5 tion, a flow chart of a method of verifying, a down- 
loaded program fragment in accordance with the siibject 
of the present .invention. 

Figure 3b represents a diagram illustrating 
data types and sub- typing relationships implemented by 
10 the method of maneging and the method of verifying a 
dovmloaded program fragment, which is the subject of 
the present invention. 

Figure 3c represents a detail of the verifi- 
cation method as claimed in figure 3a,. relating to the 
15 managing of a breoiching instruction. 

Figure 3d represents a detail of the verifi- 
cation method as claimed in figure 3a, relating to the 
managing of a subroutine-call instruction, 
^ - Figure 3e represents a detail of the verifi- 

20 cation method as claimed in figure 3a, relating to the 
managing of an exception-handler target,. 

Figure 3f represents a detail of the verifi- 
cation method as claimed in figure 3a, relating to the 
managing of a target of inconQ>atible branchings i 
25 - Figure 3g represents a detail of the verifi- 

cation method as claimed in figure 3a, relating to the 
managing of an absence of branching target. 

Figure 3h represents a detail of the verifi- 
cation method as claimed in figure 3a, relating to the 
30 managing of the effect of the current instruction on 
the type stack. 

Figure 3i represents a detail of the verifi- 
cation method as claimed in figure 3a, relating to th 
managing of an. instruction for r ading a register, 
35 - Figure 3j represents a detail of the verifi- 

cation method as claimed in figure 3a, relating to the 
managing of an instruction for writing to a register, . 
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Figure 4a r«pre8ente a flow chart illustrat- 
irig a method of transforming an object cod of a pro- 
gram fragment into a standardized object code . for this 
SEone program fragment with a branching instruction, r - 
5 spectively a branching- target instruction, with an 
. ei^pty stack, 

Figure 4b represents a flow chart illustrat- 
ing a method of transforming an object code of a pro- 
gram fragment into a standardized object code for this 
10 same program fragment, making use of typed registers, a 
single, specific data type being attributed to each reg- 
ister. 

Figure 5a r-epresents a detail of implementa- 
tion of the transfomiation method illustrated in figure 
15 . 4a, 

- Figure 5b represents a detail of ixuplementa- 
tion of the transformation method illustrated in figure 
4b, 

Figure 6 represents a functional diagram of 

20 the complete architecture of a system for development 
of a standardized program fragment, and of a reprogram- 
mable microprocessor card allowing . implementation of 
the protocol for managing and the method of verifying- a 
program fragmiKit in accordance with the subject of the 

25 present invention. 

In general, it is indicated that the protocol 
for managing and the method of verifying and transfom- 
ing a downloaded program fragment, which is the siibject 
of the present invention, and the corresponding sys- 

30 terns, are inplemented thanks to a software architecture 
for secure downloading and execution of applets on an 
on-board data-processing system with few resources, 
such as, in particular, microprocessor cards. 

In general, it is indie t d that th description 

35 below concerns the application of the invention in the 
context of reprogrammable microprocessor cards of 
JayaCard type, cf » documentation available electroni- 
cally from the company SUN MIGROSYSTEMS INC. , JavaCard 
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Technology heading mentioned previously in the descrip- 
tion. 

/ However, the present invention is applicable to 

any on-board system which is reprogrammable by dovm- 
5 loading an applet . which is written in the code of a 
virtual machine including an execution stack, local 
variables or registers, and of which the execution 
. • model is strongly typed, each instruction of the code 
of the applet applying only to specific data types, "The 
10 protocol for managing a program fragment downloaded 
onto a reprograinmable on-board system, which is the 
subject of the present invention, will now be described 
in more detail with reference to fig. 2. 

With reference to the abovementioned figure, it 
15 is indipated that the object code which makes up the 
program fragment or applet consists of a series of in- 
structions which can be executed by the microprocessor 
of the on-board system by means of the abovementioned 
r( virtual machine. The- Virtual xnachine makes it possible 

20 to interpret the abovementioned object code. 

The c?i-board system- is interconnected to a terminal 
via, for instance, a serial link. 

With reference to the abovementioned fig. 2, the 
management protocol which is the subject of the present 
= 25 invention consists at least, in the on-board system, 
in detecting a command to download this program frag- 
ment in a stage lOOa, 100b, Thus, stage 100a may con- 
sist of a stage of reading the abovementioned cOtnmand, 
and stage 100b of a stage of testing the command which 
30 has been read and verifying the existence of a down- 
loading command. 

On a positive response to the abovementioned 
stage lOOa, 100b of detecting a downloading command, 
the protocol which is the subject of th present inven- 
.( 35 tion subsequently consists in reeding, at stage 101, 

; . the object cod which makes up the relevant program 
fragment, and terrporarily storing the abovementioned 
object code in the memory of the on-board data- 
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processing system. Th , abovexnentioned temporary storing 
operation can be executed either in the rewritable mem- 
ory or, if appropriate, in the random-access memory of 
the on-board eyetem, when this has sufficient capacity, 
5 The stage of reading the object code and terr^orarily 
storing it in the rewritable memory is designated as 
loading the code of the applet in fig. 2. 

The abovementioned stage, is then followed a 
stage 102 consisting in submitting the whole of the 

10 temporarily stored object code to a process of verifi- 
cation^ . instxruction by instruction, of the abovemen- 
tioned object code. 

The verification process consists, at least in a 
stage of initializing the stack of types and the table 

15 of data types representing the state of the virtual ma- 
chine at the start . of execution of the terrporarily- 
stored object code, and in a succession of stages of 
verifiying, instruction by instruction, by discerning 
the existence, .for each current instruction, designated 

20 Zi, of a target such as a branching- instruction target 
designated CIB, a target of an exceptionrhandler call 
or a target of a subroutine call. A verification and 
update of the effect of the cuarrent instruction li on 
the stack of types, and on the table of register types 

25 is carried out. 

When the verification has been successful at 
stage 103a, the protocol which is the subject of the 
present invention consists in recording, at stage 104, 
the downloaded program fragment in a directory of 

30 available program fragments, and in sending to the 
reader, at stage 105, a positive reception acknowledg- 
ment. 

On the other hand, in the case of unsuccessful 
verification of th object code at stage 103b, th pro- 
35 tocol which is the subject of th pr sent invention 
consists in inhibiting, in a stage 103c, any execution 
on the on-board system of the momentarily recorded pro- 
gram fragment. Ihe inhibition stage 103c can be imple- 
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xriented in various vrays*: A3 a nonlimiting exairple* this 
£t.age can consist in deleting* at stage 106, the momen- 
tarily recorded program fragment, without recording 
this program fragment in the directory o£ available 
5 program fragments and, at stage 107, in sending an er- 
ror code to the reader. Stages 107 and 105 can be im- 
plemented eith^ sequentially after stages 106 and 104 
respectively, or in multitasking operation with them. 

With reference to the same fig. 2, on a negative 

10 response to the stage consisting in detecting a down- 
loading command at stage lOOh, the protocol which is 
the sxabject of the present invention consists in de- 
tecting, in a stage 108/ a command to select an avail- 
able program fragment from a directory of program frag-^ 

15 ments and, on a positive response to stage 108, having 
detected the selection of an available program frag- ' 
ment, in calling, at stage 109, this selected available 
program fragment in order to execute it. Stage 109 is 
then followed by a stage 110 of executing the called 

20 available program fragment by way of the virtual ma- 
chine, with no dlynamic verification of variable types ^ 
rights of access to the objects which are manipulated 
by the called available program fragment, or overflow 
of the execution stack when each instruction is exe- 

25 . cubed. 

In the case where a negative response is ob- 
tained at stagre 108, this stage consisting in detecting 
a command to select a called available program frag- 
ment, the protocol which is the subject of the present 

30 invention consists in proceeding, in a stage 111, to 
process the standard commands of the on-board system. 

Regarding the absence of dynamic verification of 
type or rights of accese to objecte of, for instance, 
JavaCard type, it is indicated that this absence of 

35 verification does not compromise th security of the 
card, because th code of the applet has necessarily 
successfully passed v rif ication. 
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More specifically, it is indicated that the code 
vGxification which is carried out, as claimed in th 
method which is the subj ct of th present invention; 
on the microprocessor card or on-board data -processing 
5 system is more selective than the customary verifica- 
tion of codes for the virtual Java machine as described 
in the work entitled "The Java Virtual Machine Specifi- 
cation" which wa.s mentioned previously in the descrip- 
tion. 

10 However, any code of the Java virtual machine 

which is correct as far as the traditional Java veri- 
fier is concerned can be transformed into an equivalent 
code which is capable of passing successfully the code 
verification which is carried out on the microprocessor 

15 card. 

Tr9hereas it is possible to imagine writing di- 
rectly Java codes which, satisfy the abovementioned 
verification criteria mentioned in the context of im- 
plementing the protocol which is the subject of the 
20 present invention^ a noteworthy object of the latter is 
' also the implementation o£ a method of automatic trans- 
.formation of any standard Java code into a standardized 
code for the same program fragment/ necessarily satis* 
fying the verification criteria ijtplemented as men- 
25 tioned above, ^e method of trans fozmat ion into stan- 
dardized code, and the corresponding system, will be 
described in detail subsequently in the description. 

A more detailed description of the method of 
verifying a program fragment, or applet, in accordance 
30 with the subject of the present invention, will now be 
given with reference to fig. 3a and the subsequent fig- 
ures. 

In general, it is indicated that the verifica- 
tion method which is the subject of the present inven- 
35 tion can be inplemented either as part of th protocol 
for managing a program fragment which is the subject of 
the present invention as described above with reference 
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to fig. 2, or independently, to provide whatever veri- 
fication process is judged necessary. 

In general, it is indicated that a program frag- 
ment is made up of an object code including at 1 ast 
5 one subprograia, more commonly designated a method, and 
is made up of a series of instructions which can be 
executed by the microprocessor of the ori-board system 
via the virtual machine. 

As shown in fig. 3a, the verification method 
10 consists, for each subprogram, in carrying out a stage 
200 of initializing the stack of types and the table of 
register types of the virtual machine by data repre- 
senting the state of this virtual machine at the start 
of execution of the object code which is the siibject of 
15 verification. This object code can be stored ten^porar- 
ily as described above vith reference to implementation 
of the protocol which is the subject of the present in- 
vention. 

rChe abovementioned stage 200 is then followed by 

20 a stage 200a consisting in positioning the reading of 
the current instruction index i, on the first in-- 
stacuction of the object code. Stage 200a is followed by 
a stage 201 consisting in carrying out a verification 
of the abovementioned object code, instruction by in- 

25 etruction, by discerning the existence, for each cur*^ 
rent instruction, designated Ii, of a branching- 
instruction target CIB, of a target of an exertion- 
handler call, designated CEH, or of a target of a sub- 
routine call CSR. 

30 The verification stage 201 is followed by a 

stage 202 of verifying and updating the effect of the 
current instruction Ii on the data types of the stack of 
types and of the table of register types, as a function 
of th existence, for the current instruction which is 

35 pointed at by another instruction, of a branching- 
instruction targ t CIB, of a targ t of a subroutine 
call CSR or a target of an exception-handler call CEM. 
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Stage 202 for the cvurrent instruction Ii is fol- 
lowed by a stage 203 to test whether the last instruc- 
tion has been reached, the test written as: 
li = last instruction of the object cod ? 

5 On a negative response to test 203^ the process passes 
to the next instruction 204, written i « i+1, and to 
the return to stage 201. 

It is indicated that the aboveinentioned verifi- 
cation, at stage 202, has been successful when the ta- 

10 ble of register types is not modified during verifica- 
tion o£ all the instnactions Ii which make up the object 
code. For this purpose, a test 205 of the existence of. 
a stable state of the table of register types and pro- 
vided. This test ifi written: 

15 3? Stable state of table of register types. 

On a positive response to test 205, verification has 
been successful. 

On the other hand, in the case where no absence 
of jnodification is noticed, the verification process is 

20 repeated and reinitiated by returning to stage 200a. It 
is demonstrated t:hat the process is guaranteed to end 
after a maximum o£ NrxH iterations, where Nr designates 
the nuinber of registers used and E designates a con- 
stant depending on the subtyping . relation • 

25 Various indications concerning the typee of 

variables which are manipulated in the course of the 
verification process described above with reference to 
fig. 3a will now be given with reference to fig. 3b. 

The abovementioned variable types include at 

30 least class identifiers corresponding to object classes 
which are defined in tthe program fragment which is s\;ib- 
jected to verification, numeric variable types . includ- 
ing at least a typ short , an integer coded on p bits, 
where the value of p can be 16, and a type for the re- 

35 turn address of a juirp instruction JSR, this address 
. . type being identified as retaddr , a type null relating 
to references of null objects, a type object relating 
to obj cts proper, a specific type i representing the 
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intersecticai of all the types and corr spending to the 
valu aero iMil, anoth r sp cific type T rcpr senting 
the union * of all the typ s and corresponding to any 
typ of values. 

5- With reference to fig. 3b, it is indicated that 

all the abovementioned variable types verify a subtyp- 
ing relation: 

object ex; 

short, retaddr cT; 

10 J. 8 null , short , retaddr 

A more specific exanple of a process of verifi- 
cation as illustrated in fig. 3a will now be given, 
with reference to a first example of a data structure, 
which is shown in table Tl in the annex. 

15 The abovementioned exanple concemfi an applet 

written in Java code. 

The verification process accesses the code of 
the subprogram which forms the applet which is sub- 
jected to verification via a pointer to instruction li 

20 which is being verified. 

The verification process records the size and 
type of the execution stack at the current instruction 
li corresponding to saloed in the exanflple of the above- 
mentioned Table Tl. 

25 The verification process then records the si^e 

and type of the execution stack at the current instruc- 
tion in the stack of types via its type stack pointer. 

As mentioned above in the description, this 
stack of types reflects the state of the execution 

30 stack of the virtual machine at the current instruction 
li. In the example shown in table Tl, at the time of the 
future execution of . instruction li, the stack will con- 
tain three entri s: a r f r nc to an object of class 
C, a reference to a table of integers coded on p = 16 

35 bits, the type short [ ] , and an integer of p « 16 bits 
of type short . This, is also shown in the type stack, 
whicii also contains three entries: C, the type of Ob- 
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jefcts pf class C, short I], the type of tables of inte- 
gers p ■ 16 bite and short , the type of integers p = 16 
bits . 

Another noteworthy data structure consists of a 
5 table of register types, this table reflecting the 
state of the registers, that is to say of the registers 
which store the local variables, of the virtual ma- 
chine. 

Continuing the example indicated in table Tl, it 
10 is indicated that . entry 0 of the table of register 
types contains type C, i.e. at the time of the future 
execution of the cujcxfoit instruction iji « saload, regis- 
ter 0 is guaranteed to qontain a reference to an object 
of class C. 

25 The various types which are manipulated during 

verification and stored in the table of register types 
and in the type stack are represented in fig. 3b* These 
types include: 

class identifiers CB corresponding to specific 
20 object classes which are defined in the applet; 

base types, such as short , an integer coded on 
p = 16 bits, intl and int2 , the most and least 
significant p bits respectively of integers 
coded on, e.g., 2p bite, or retaddr , the return 
25 address of an instruction as mentioned above; 

the type null , representing the references of 
null objects. 

Regarding the subtyping relation, it is indi- 
cated that a type Tl is a subtype of a type T2 if every 

30 valid value of type Tl is also a valid value of type 
T2. The subtyping between class identifier reflects the 
inheritance hierarchy between classes of the applet. On 
the other types, subtyping is defined by the lattice 
shown in fig. 3b, where J, is a subtype of all types and 

35 . all types are subtypes of T. 
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The sequenqe of the process of verifying a Bub- 
program which forms an applet is as follows, r f erring 
to the abovementioned table Tl. 

The verification process is carried out inde- 
5 pendently on each svlqprograiti of the applet* For each 
svibprogrami the process carries out one or more verifi- 
. cation passes on the instructions of the relevant, sub- 
program. The pseudocode of the verification process is 
given in table T2 in the annex. 

10 . 'The process of verifying a subprogram begins 

with initializing the type stack and the table of reg- 
ister types shown in table Tl, this initialization re- 
flecting the state of the virtual machine at the start 
of execution of the subprogram being examined* 

15 The type stack is initially eirpty, the stack 

pointer equals 2:ero, and the register types are ini- 
tialized with the types of the parameters of the s\ab- 
program, illustrating the fact that the virtual machine 
passes the parameters of this subprogram in these reg- 

20 isters. The register types which are allocated by the 
subprogram are initialized to data types J;,, illustrat- 
ing the fact that the virtual machine initializes these 
registers to zero at the start of execution of the sub- 
program. 

25. Next, one or more verification passes on the in** 

structions and on each current instruction Zi of the 
subprogram are carried out. 

At the end of the implemented verification pass, 
or of a succession of passes for instance, the verifi- 

30 cation process determines whether the register types 
contained in the table of register types shown in table 
Tl of the annex have changed during the verification 
pass. In the absenc of chang , v rification is termi- 
nated and a success code is returned to the main pro- 

35 gram, which makes it possible to send the positive re- 
ception acknowledgment at stage 105 of the management 
protocol shown in fig» 2. 



W> 01/14958, - 23 - PCT/FllOO/02349 

If a chaiige to th eOjovementioned table of r g- 
ister types is present, the verification process re- 
peats the verification pass until th register types 
contained in the table of register types is stable. 
5 Tflie sequence proper of a verification pass whi<di 

is carried out one or more times until the table of 
register types is stable will now be described with 
reference to figs. 3c to 3 j . 

For each current instruction li, the following 
10 verifications are carried out: 

With reference to fig. 3a at stage 201, the 
verification process deterrainee whether the current in- 
struction li is the target of a branching instruction, a 
subroutine call or an exertion-handler call, as men- 
15 tioned above. This verification is carried out by exam- 
ining the branching instructions in the code of the 
subprogram and the- exertion handlers associated with 
this subprogram. 

Witb reference to fig- 3c which begins with 
20 stage 201, when the current instruction Ii ie the target 
of a branching instruction, this condition being imple- 
mented by a test 300 designated by li = CIB, this 
branching being unconditional or conditional, the veri- 
fication process checks that the type stack is empty at 
25 t±iiB point of the subprogram by a test 301. On a posi- 
tive response to the test 301, the verification process 
is continued by a context continuation stage marked 
continue A. On a negative response to the test 301, the 
type stack not being empty, the verification fails and 
30 the applet is rejected. This failure is represented by 
the Failure stage. 

With reference to fig. 3d which begins with the 
continue A stage, when the current instruction Ii is the 
target of a eubroutin call, this condition being im- 
35 plemented by a test 304 Ii = CSR, the verification proc- 
ess verifies, in a test 305, that the previous Instruc- 
tion It-i does not continue in sequence. This verifica- 
tion is iii5>lemented by a test stage 305 when the previ- 
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ouB instruction is. an unconditional branching, a buU- 
rwtine return or a raising of an exception. The test 
^ at stage 305 is marked as follows: 

= IBunco«»ti««i, return RSR or raising h- 

5 EXCEPT . 

On a negative response to test 305, the verifi- 
cation process fails in a Failure stage. On the other 
hand, on a positive response to test 305. the verifica- 
tion process reinitializes the type stack in such a way 

10 that it contains exactly one entry of retaddr type, the 
return address of the abovementioned subroutine, if the 
current instruction li at stage 304 is not the target of 
a subroutine call, the verification- process is contin- 
ued in the context at the continue B stage. 

15 With reference to fig. 3e, when thB current in- 

struction li is the target of an exception handler, this 
condition being iirplemented by a test 307 marked li « 
CBM, where CEM designates the target of an exception 
( handler, this condition is iiqplemented by a test 307, 

20 marked: 

li = CEM. 

On a positive response to test 307, the process veri- 
fies that the previous instruction is an unconditional 
branching, a subroutine return or a raising of excep- 
25 tions by a test 305, marked: 

li-i « lB,^«iditio4*i, return RSR or raising L- 

EXCEPT. 

On a positive response to test 305, the verifi- 
cation process proceeds to reupdate the type stack, at 
30 a stage 308, by entering exception types, marked EXCEPT 
type, stage 308 being followed by a context continua- 
tion stage, continue C. On a negative response to test 
305, the verification process fails by the stage marked 
Failure. The program fragment is then rejected. 
( 35 With reference to fig. 3f , when the current in- 

, struction Ii is the target of multiple incompatible 
branchings, this condition is implemented by a test 
309, which is marked: 
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li ■ inconpiatible TJSs 
incoxnpatible branchingp being, for instanc , an uncon- 
ditional brandling and a sviDroutine call, or t.*© dif- 
ferent exception handlers. On a positiv response to 
test 309, the branchings being incompatible, the veri- 
fication process fails by a stage niarlced Failure and 
the program fragment is rejected. On a negative re- 
sponse to test 309, the verification process is contin- 
ued by a stage jnarked continue D. Test 309 begins with 
the continue C stage which was mentioned previously in 

the description. 

With reference to fig. 3g, when the current in- 
struction li is not the target of any branching, this 
condition being implemsnted by a test 310 beginning 
with the abovexnentioned continue this test being 

marked 

ii 3? branching targets, 

where B designates the existence symbol, 
the verification procesB continues on a negative re- 
sponse to the test 310 by passing to an update of the 
type stack at stage 311. stage 311 and the' positive re- 
sponse to test 310 being followed by a context con- 
tinuation stage at stage 202. which is described above 
in the description with reference to fig. 3a. 

A more detailed description of the stage of 
verifying the" effect of the current instruction on the 
type stack at the abovementioned stage 202 will now be 
given with reference to fig. 3h. 

According to the abovementioned figure, this 
stage can include at least one stage 400 of verifica- 
tion that the type execution stack includes at least as 
niany entries as the current instruction includes oper- 
ands. This test stage 400 is narked: 

Nbep ^ NOpi 

where Nbep designates the nuiriber of entries of the type 
stack and NOpi designates the nuiriber of operands in- 
cluded in the current instruction. 
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On a positive response to test 400, this test i« 
followed by a stage 4016 of unetacJcing the type stack, 
and of verifying 401to that th types of th entries at 
' the top of the stack are subtypes of the typee of the 
5 operands of the abovementioned current instruction* At 
test stage 401a, the operand types of the instruction i 
are marked TOpi, and the types of the entries at the 
top of the stack are marked Targs.* 

At stage 401b, the verification corresponds to a 
10 verification of the siibtyping relation Targs subtype of 
Tppi. 

On a negative response to tests 400 and 401br 
the verification process fails, which is shown by ac- 
cess to the Failure stage. On the other hand, on a 

15 positive response to test 401b, the verification proc- 
ess is continued, and consists in carrying out: 

- A stage of verifying the existence of a suffi- 
cient ineniory space on the type stack to proceed to 
stack the results of the current instruction. Tliis 

20 verification stage is implemented by a test 402, 
marked: 

Stack- space ^ Results-space 
where , each side of the inequality designates the corre- 
sponding m^ory space. 

25 On a negative response to test 402, the verifi- 

cation process fails, which is shown by the Failure 
stage. On the other hand, on a positive response to 
test 402, the verification process then proceeds to 
stack the data types* which are assigned to the results 

30 in a stage 403, the stacking being done on the stack of 
data types which a^re assigned to these results. 

As a nonlimiting example, it . is indicated that 
to intplement fig. 3h for verifying the effect of the 
current instruction on the type stack, for a cTirrent 

35 instruction consisting of a Java saload instruction 
corresponding to reading an integer element coded on p 
^ 16 bits in a table of integers, this table of inte- 
gers being defined by the table of integers and an ii^- 
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t ger index in this table, and the reeult th inte- 
ger which is read at this index in this table, th 
verification process checks that th typ stack con- 
tains at least two elemeats, that the two elements at 

5 the top of the type stack are subtypes of short [ 3 and 
short respectively, proceeds to the uns tacking process 
and then to the process of stacking the data type short 
as the result type. 

Additionally, with reference to fig. 3i, to im- 

10 pl'ement the stage of verifying the effect of the cur- 
rent instruction on the type stack, when the current 
instruction li is a read instruction, marked IR, of a 
register of address h, this condition being implemented 
by a test 404 marked li = IRn, on a positive response to 

15 the abovementioned test 404, the verification process 
consists in verifying the data type of the result of 
this reading, in a stage 405, by reading the entry n in 
the table of register types, then in determining the 
effect of the current instruction Ii on the type stack 

20 by an operation 406a of unstacking the- entries of the 
stack correspcmding to the operands of this current in- 
struction and by stacking 406b the data type of this 
result, ^e operands of the instruction Ii are marked 
OFi. Stages 406a and 406b are followed by a return to 

25 the context continuation, continue P. On a negative re- 
sponse to test 404, the verification process .is contin- 
ued by the context continuation, continue F. 

With reference to fig. 3j/ when the current in- 
struction Ii is a write instruction, marked IW, of a 

30 register of address n, this condition being iirplemented 
by a test marked Ii = IV^«, on a positive response to 
test 407, the verification process consists in deter- 
mining, in a stage 408, the effect of the cxurrent in- 
struction on the type stack and th type t of the oper- 

35 and which is written in the register of address n, 
then, in a stage 409, in replacing the typ entry of 
t;,he tabl of register types at address n by the type 
immediately above the previously stored typ and above 
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the type t of the operahfl which is written in the reg- 
ister of address n. Stage 409 is followed by a retum 
to the context contimiation, continue 204. On a nega- 
tive response to test 407, the verification procesB ie 
5 continued Iv a context continuation, continue 204. 

As an example, when the current instruction Ii 
corresponds to writing a value of type D into a regis- 
ter of address 1, and the type of register 1 before' 
verification of the instruction was C, the type of reg- 
ie ister 1 is replaced by the type object , which is the 
smallest type which is higher than C and D in the .lat- 
tice of types shown in fig. 3b. 

In the same way, as an exaii5)le, when the current 
instruction Ii is a read of an instruction aload-0 con- 
15 sisting in stacking the contents of register 0, and en- 
try 0 of the table of register types is C, the verifier 
stacks C onto the type stack. 

An example of verifydLng a 6\ibprogram written in 
a Java environment will now be given, with reference to 
20 tables T3.and T4 in the annex. 

Table T3 represents a * specific JavaCard code 
.corresponding to the Java subprogram which is included 
in this table. 

table T4 shows the contents of the table of reg- 
25 . ister types and of the type stack before verification 
of each Instruction. The type constraints on the oper- 
ands of the various instructions are all observed. The 
stack is eapty both after the instrtiction 5 to branch 
to instruction 9, symbolized by the arrow, and before 
30 the abovementioned branching teurget 9. Ihe type of reg- 
ister 1/ which was initially JL, becomes null , the upper 
bound of null and i , when instruction 1 to store a 
value of type null in register 1 is examined, then be- 
comes of type short [1, the upper bound of types short [ 3 
35 and null , when instruction 8 to store a value of type 
short [3 in register 1 is processed. The type of regis- 
. t r 1 having changed . during the first verification 
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P99«., a second pass is carried out, distributing regis- 
ter types wbich were obtained at the ^d of the first. 
This second verification pass is successful, just like 
th first, and does not change the register types. The 
verification process thus terminates successfully. 

Various exait^les of cases of failure of the 
verification process on four exarnples of incorrect code 
will now be given with reference to table T5 in the an- 
nex: 

At point a) of table T5/ the purpose of the code 
given as an exanjple is to attempt to fabricate 
an invalid object reference using an arithmetic 
process on pointers. It is rejected by verifica- 
• tion of the types of arguments of instruction 2 
sadd, which requires these two arguments to be 
of type short . 

At points b) and c) of table T5, the purpose of 
the code is to carry out two attengpts to trans- 
form any integer into an object reference. At 
point b) , register 0 is used 'simultaneously with 
type short , instruction 0, and with type null , 
instruction 5. Consequently, the verification 
process assigns type T to record 0, and detects 
a type error when register 0 is returned as a 
result of type object at instruction 7 . 
At point c) of table T5, a set of branchings of 
type -if ... then . . . else ..." is used to leave 
at the top of the stack a result which consists 
of either an integer or an object reference. The 
verification process rejects this code because 
it detects that the stack is not empty at the 
branching from instruction 5 to instruction 9, 
symbolized by the arrow. 

Finally, at point d) of table 5, the code con- 
tains a loop which, at each iteration, has the 
effect of staclcing an additional integer on the • 
top of the stack, and thus causing a stack over- 
flow after a certain number of iterations. The 
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verification process rejects this code, noticing 
that the stack is not enpty at the backward 
branching from instruction 8 to instruction 0, 
symbolized by the return arrow, the stack not 
5 being empty at a branching point. 

Ihe various examples given above with reference 
to tables T3, T4 and T5 show that the verification 
process, which is the subject of the present invention^ 
is particularly efficient, and that it applies to ap- 
10 pletS/ and in particular to subprograms thereof, for 
which the conditions of stack type, or . respectively of 
the enpty character of the type stack previously, and 
to the branching instructions or branching targets, are 
satisfied. 

15 Obviously, such a verification process implies 

writing object codes which satisfy these criteria, 
these object codes possibly corresponding to the sub-- 
program in the abovesnentioned table T3. 

However, and in order to ensure verification of 

20 existing applets and subprograms of applets which do 
not necessarily satisfy the verification criteria of 
the method which is the subject of the present inven- 
tion, in particular regarding applets and subprograms 
which are written in the Java environment, the purpose 

25 of the present invention is to' establish methods of 
transforming these applets or subprograms into stan- 
dardized applets or program fragments, mald.ng it possi- 
ble to undergo successfully the verification tests of 
the verification method which is the subject of the 

30 present invention and of the management protocol which 
implements such a method- 

Por this purpose, the subject of the invention 
is the itt^lementaticn of a- method and a program for 
transforming traditional object code forming an ap- 

35 plet, it being possible to inplement this method and 
this transformation program, outsid an on-board system 
or microprocessor card, when the relevant appl t is 
created. 
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: . The method of. transforming code into standard- 
' ized cpde, which is the subject of th present inven- 

. tion, will now be describ d in th framework of the 

Java environm nt, as a purely illustrative exaicqple* 
5 The JVM codes which are produced by existing 

Java coirpilers satisfy various criteria, which are 
stated below: 

CI: the arfluments of each instruction actually be- 
long to the types which this instruction ex- 
10 pects; 

C2: the stack does not overflow; . 

C'3s for each branching- ins true tion, the type of the 
stack at this branching is the sanie as at the 
possible targets for this branching; 
15 C*4: a value of type t which is written into a regis- 
ter at one point of the code and reread from the 
same register at another point of the code is 
always reread, with the same type t; 
( The inplementation of the verification method 

20 which is the subject of the present invention implies 
that criteria C*3 and C"4, which are verified by the 
object code which is submitted for verification, be re- 
placed by criteria C3 and C4 below; 

C3s the stack is enpty at each branching instruction 
25 and at each branching target; 

C4: the same register is used with one and the same 

type throughout the code of a subprogram* 
With reference to the abovementioned criteria^ 
it is indicated that Java compilers guarantee only the 
. 30 weaker criteria C'3 and C'4, The verification process 
which is the subject of the present invention and the 
corresponding management protocol in fact guarantee 
more restrictive criteria C3 and C4, making it possible 
to ensure the security of execution and management of 
( 35 applets. 

The concept of standardization^ covering the 
transformation of codes into standardized cod can 
present various aspects^ to the extent that replacement 
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of cjciteria C'3 and C'4 by criteria C3 and C4, in con- 
fonnity with the verification proceeB which is the sub- 
ject of the present invention, can b iir?>lemented inde- 
pendently, to ensure that the stack is einpty at each 
branching instruction and at each branching target, and 
respectively that the registers which the applet opene 
are typed, and a single data type which is assigned for 
execution of the relevant applet corresponds, to each 
open register, or. on the other hand, jointly, to sat- 
isfy the whole of the verification process which is the 
subject of the present invention. 

.The method of tranBfomdng an object code into 
standardized object code as claimed in the invention 
will consequently be described as claimed in two di«- 
15 tinct inplementation modee, a first in^^l amenta ti on mode 
corresponding to transformation of an object code which 
satisfies criteria CI. C2, C'3. C'4 into a standardized 
object code which eatisfies criteria CI. C2, C3. C'4 
corresponding to a standardized code with an eitpty 
branching instruction or branching target, then, as 
claimed in a second inplementation xnode. in which the 
traditional object code which satisfies the same ini- 
tial criteria is transformed into a standardized object 
code vrtiich satisfies criteria Cl, C2, C'3, C4, for in- 
stance corresponding to a standardized code using typed 
. registers. 

The first inplementation mode of the code trans- 
formation method which is the subject of the present 
invention will now be described with reference to fig. 
30 4a. In the implementation mode which is shown in fig. 
4a. the initial traditional code is considered to sat- 
isfy criteria Cl+C2+C'3. end the standardized code 
which , is .obtained as the result of the transformation 
is considered to satisfy criteria C1+C2+C3. 

According to the abovementioned figure, the 
transformation method consists, for each current in- 
struction li of the code or of the subprogram, in anno- 
tating each instruction, in a stage 500, with the data 
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t.yp&: of the stack before and aft x execution of this 
instruction i The annotation data is marked AIi and is 
associated by the relation Iif^AIi with th relevant 
current instruction. The annotation data is calculat d 
5 by means of an analysis of the data stream relating to 
this instruction. The data types before and after exe- 
cution of the instruction are marked tbei and taei re- 
spectively. Calculation of annotation data by analysis 
of the data stream is a traditional calculation which 
10 is Icnown to those skilled in the art, and will there- 
fore not be described in detail. 

The <:>peration which is iinplemented at stage 500 
is illustrated in table. T6 in the annex, in which, for 
an applet or subprogram of an applet including 12 In- 
15 structictfis, the annotation data AIi made up of the types 
of registers and the types of the stack are introduced. 

The aboveinentioned stage 500 is then followed by 
a stage 500a consisting in positioning the index i on 
the first instruction li a li. Stage SOOa is followed' by 
20 a stage 501 consisting in detecting, among the instruc- 
tions and in eadki current instruction li, the existence 
• of branchings marked IB or of branching targets CIB for 
which the execution stack is not en5>ty. This detection 
501 is implemented, by a test which is carried out on 
25 the basis of the annotation data AIj of the type of 
stack variables allocated to each current instruction, 
the test being marked for the current instruction j 
Ii is an IB or CIB and stack (AI) ? eirpty. 
On a positive response to test 501, i.e. in the 
30 presence of detection of a non-empty execution stack, 
the abovementioned test is followed hy a stage consist- 
ing in inserting instructions to transfer stack vari- 
ables on either side of these branchings IB or branch- 
ing targ ts CIB, in order to enpty the content of the 
35 execution stack into temporary registers before this 
branching and to reestablish th execution stack from 
the temporary, registers after this branching. The in- 
. sertion stage is marked 502 in fig. 4a. It is followed 
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by a Btage 503 to test reaching th last instruction, 
narked 

li s last inetructlon? 
On a negative response to the test 503, an increment 
5 504 i=i+l is carried out, to go on to the next instruc- 
tion and return to stage 501. On a positive response to 
test 503, an End stage is initiated. On a negative re- 
sponse to test 501, the transformation method is con- 
tinued by a branching to stage 503 in the absence of 

10 insertion of a transfer instruction. Inrplementatioa of 
the method of transforming a traditional code into a 
standardized code with branching instruction with empty 
stack as represented in fig. • 4a makes it possible to 
obtain a standardized ol:>jec.t code for the same initial 

15 program fragment in which the stack of stack variables 
is empty at each branching instruction and each branch- 
ing-target instruction, in the absence of any modifica- 
tion to the execution, of the program fragment. In the 
case pf a Java enviroiment^ the instructions to trans-* 

20 fer data between stack and register are the load and 
store instructions of the Java virtual machine. 

Returning to the exaiqpld introduced in table T6, 
the transformation method detects a branching target 
where the stack is not empty at instruction 9. The 

25 method is then to insert an instruction i store 1 before 
the branching instruction 5 which leads to the above- 
mentioned instruction 9, in order to save the content 
of the stack in register 1 and ensure that the stack is 
ertpty at the time of the branching ♦ Symmetrically/ an 

30 instruction iload 1 is inserted before the instruction 
target 9, to reestablish the content of the stack ex- 
actly as it was before the branching* Finally, an in- 
struction is tore 1 is inserted after instruction 8 to 
ensure that the stack is balanced on the two paths 

35 which lead to instruction 9. Hie result of the trans- 
fonnation carried out in this way into a standardized 
code is shown in tab^e T7. 
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The second irnplementation mode of th transfor- 
mation method which is the subject of the present in- 
^ vention will now be described with reference to fig- 4b 

in the case in which the initial traditional obj ct 
5 code satisfies criteria Cl+C'4 and the standardized ob- 
ject code satisfies criteria C1+C4. 

With reference to the abovementioned fig* 4b, it 
is indicated that the method, in this ixuplementation 
mode, consists in aimotating, as claimed in a stage 500 
10 which is approximately the same as that which is shown 
in fig. 4a, each current instruction Ij, with the type of 
register data before and after execution of this in- 
struction. In the same way, the annotation data Ali ie 
calculated by means of an analysis of the data stream 
15 relating to this instruction- 

The annotation stage. 500 is then followed by a 
stage consisting in carxying out a reallocation of the 
registers, the stage marked 601, by detecting the 
* . original registers employed with different types, by 

20 dividing these original registers into separate stan- 
dardized registers, one standardized, register being al- 
located to each data type used. Stage 601 is followed 
by a stage 602 of reupdating the instructions which ma- 
nipulate the operands which use the abovementioned 
25 standardized registers. Stage 602 is followed by a con- 
* text continuation stage 302. 

With reference to the exaanple given in table T6, 
it is indicated that the transformation method detects 
that the register of rank 0, marked rO, is used with 
30 the two types, object , instructions 0 and 1, and int , 
instruction 9 and following. The method is then to di- 
vide the original register rO into two registers, reg- 
ister 0 for the use of object types and register 1 for 
uses of int type. Referenc s to record 0 of int type 
( 35 are then rewritten by transforming them into referenc s 

to record 1, the standardized cod obtained being shown 
in tabl T8 in the annex. 
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It is noted, in a nonlimiting way, that in the 
exanple which is introduced with r f erejice to the 
abovementioned tabl6 T8, the new register 1 is used si- 
multaneously for standardization of th stack and for 
5 creation of typed registers by dividing of register 0 
into two registers. 

The method of transforming a traditional code 
into a standardized code with branching instruction 
with empty stack as described in f ig» . -^a will now be 
10 described in more detail in a preferred, nonlimlting 
ixtplementation mode, in. relation to fig. 5a* 

This implementation mode concerns stage 501, 
consisting in detecting, within the instructions and 
within each current instruction li, the existence of 
15 branching IB, or respectively of branching target CIB, 
for which the stack is not einpty. 

Following the detexniination of target instruc- 
tions where the stack is not ejnnpty, this condition be- 
ing marked at stage. 504a, li stack^erapty, the transfor- 
20 mation process consists in associating with these in- 
structions, at the abovementioned stage S04a, a set of 
new registers, one per ' stack location which is active 
at these instructions. "Thus, if i designates the rank 
of a branching target of which the associated stack 
25 type is not ertpty and is of type tpli to tpni with n > 
0, stack not empty, the transformation process allo- 
cates n new, as yet unused, registers, ri to Xm and as- 
sociates them with the corresponding instruction i. 
This operation is implemented at stage 504a. 
30 Stage 504a is followed by a stage 504 consisting 

in examining each detected instruction of rank i and 
identifying, in a test stage 504, the existence of a 
branching target CIB or of a branching IB. Stage 504 is 
shown in the form of a test designated by: 
35 3?aBJBandIi«=ciB. 

In the case that the instruction of rank i is a 
. branching t^irget CIB represented by the preceding 
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equality, and that thj : stack of stsck varlaibles at this 
instruction is not empty, i.e. with a positiv response 
to test 504, for every preceding instruction of rank 
i-1 consisting of a branching, raising of an excep- 
tion or a program return, this condition is implemented 
at test stage 505, designated by: 

li.i = IB, EXCEPT raising, Prog, return. 
The detected instruction of rank i is only accessible 
by a branching. On a positive response to the abovemen- 
tioned test 505, the transformation process consists in 
carrying out a stage 506 consisting in inserting a set 
of load instructions of load type from the set of new 
registers before the relevant detected instruction of 
rank ±. The insertion operation 506 is followed by a 
redirection 507 of all branchings to the detected in- 
struction of rank i, to the first inserted load in- 
struction load* The insertion and redirection opera-- 
tions are shown in table T9 in the annex. 

For every preceding instruction of rank i-1 con- 
tinuing in sequence, i.e. when the current instruction 
of rank i is accessible sincultaneously by a branching 
and from the preceding instruction, this condition be- 
ing implemented by test 508 and symbolized by the rela- 
tions: 

and 

the transformation process consists in a stage 509 of 
inserting a set of backup instructions store to back up 
to the set of new registers before the detected in-^ 
struction of rank i^ and a set of load instructions 
loa_d to load from this set of new registers. Stage 509 
is then followed by a stage 510 of redirection of all 
the branchings to the detect d instruction of rank i to 
the first ins rt d load instruction load . 

In the cas that the d tected instruction of 
rank i is a branching to a determined instruction, for 
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aiiy detected instruction :bf rank i coneisting of an im- 
cqnaitibnal branching, this condition being iinplemented 
by a teet 511 marked: 

Xi==^ jBimcondit * 

the transformation process as shown in fig. 5a consists 
in inserting at a stage 512, on a positive response to 
test 511, before the detected instruction of rank i, 
multiple bacloip instructions store . The transformation 
process inserts before the instruction i the n instruc- 
tions store as shown in table Til as an example. The 
instructions store address registers ri to r^, where n 
designates the number of registers. Thus the backup in- 
struction is associated with each new register. 

For every detected instruction of rank i con- 
sisting of a conditional branching, and for a number 
mpp, greater than 0, of operands manipulated by this- 
conditional branching instruction, this condition being 
inclement ed by the teet 513 marked: 

li«lBc<todit. 
with itiOp > 0 

the transformation process, in positive response to the 
abovementioned test 513, consists of inserting, at a 
stage 514 before this detected instruction of rank i, a 
peiiiraatation instruction marked swap^jx at the top of the 
stack of stack variables of the mpp operands of the de- 
tected instruction of rank i and the n following val- 
uer ^ This permutation operation makes it possible to 
collect at the top of the stack of stack variables the 
n values to be backed up in the set of new registers ri 
to rn. Stage 514 is followed by a stage 515 consisting 
in inserting, before the instruction of rank i, a set 
of backup instructions store to back up to the set of 
new registers r^ to rn. The abovementioned ins rtion 
stage 515 is itself follow d by a stage 516 of inser- 
tion, after the detected instruction of rank i, of a 
set of load instructions load to load from the set of 
new r gisters ri to rn. The set of corr spending ins r- 
tion operations is shown in table 12 in the annex. 
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For reasons of qi>it5)leteness and with reference 
to fig. 5a, it is indicated that, on a . negativ re- 
spqns to test 504, the continuation of the transforma- 
tion proc 68 is iii«)leinented by a context continuation 
5 stage, continue 503, that the negative response to 
tests 505, 508, 51X and 513 is itself followed by a 
continuation of the transformation process via a con- 
text continuation stage, continue 503, and that the 
same applies to the continuation of operations after 
10 the abovementioned redirection stages 507 and 510 and 
insertion stages 512 and 516. 

A more detailed description of the method of 
standardizing and transforming an object code into a 
standardized object code using typed registers as de- 
ls scribed in fig. 4b will now be given with reference to 
fig. 5b. This iitflplementation mode concerns, more par- 
ticularly, a nonliffliting, preferred inplemcntation mode 
of stage 601 to reallocate registers by detecting the 
original registers used with different types. 
20 With reference to the abovemei^tioned fig.' 5b, it 

is indicated that the abovementioned stage 601 consists 
in detexroining, in a stage 603, the lifetime intervals 
marked IDj of each register r^. These lifetime inter- 
vals, designated "live range* or 'webs', are defined 
25 for a register r as a maximum set of partial traces 
such that register r i« live at all points of these 
traces. For a more detailed definition of these con- 
cepts, it is useful to refer to the work edited by Ster 
ven S. MUCHNICK entitled "Advanced Compiler Design and 
30 IiiTplemcntation- , Section 16.3, Morgan KAtJFMANN, 1997. 
Stage 603 is designated by the relation: 
lDj< — >rj 

as claimed in which a corresponding lif time interval 
IDj is associat d with each register rj. 
35 The abovementioned stage 603 is followed by a 

stage 604 consisting in determining, at stage 604, the 
main data type, markjed tp,, of each lifetime interval 
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jDj, The main type of a lifetime interval IDj, for a 
register r^, is defined by the upper bound of the data 
types stored in this register rj by the bac3cup instruc- 
tions store belonging to the abovementicMied lifetim 

5 interval . 

Stage 604 is itself followed tqr a stage 605 con- 
sisting in establishing an interference graph between 
the lifetime intervals as defined above at stages 603 
and 604, this interference graph consisting of a non- 
10 • oriented graph of which each peak consists of a life- 
time interval, and of which the arcs, marked aji.js on 
fig. 5b, between two peaks IDji and IDja, exist if a. peak 
contains a backup instruction addressed to the register 
of the other peak or vice versa. In fig. 5b, the con- 

15 Btruction of the interference graph is shown symboli- 
cally, it being possible to inclement this construction 
on the basis of calculation techniques which are known 
to those skilled in the art. For a more detailed de- 
. scription of the construction of this type of graph, it 

20 is useful to refer to the work published by Alfred V. 
AHO, Ravi SETHI and Jeffrey D. ULLMAN entitled 
■Con?pilers: principles, techniques, and tools', Addi- 
son-Wesl^ 1986, Section 9.7. 

Following stage. 605, the standardization method 

25 as shown in fig. 5b consists in translating, in a stage 
606, the txnigueness of a data type which is allocated 
to each register r^ in the interference graph, by adding 
arcs between all pairs of peaks of the interference 
graph while two peaks of a pair of peaks do not have 

30 the same associated main data type. It is understood 
that the translation of the character of uniqueness of 
a data type which is allocated to each register obvi- 
ously corresponds to translating and taking into ac- 
count criterion C4 in the interf rence graph, this cri- 

35 terion being mentioned previously in the description. 
Ihe abovementioned stag 606 is then followed by a 
stag 607 in which an instantiation of the interference 
graph is carried out, this instantiation being more 
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. commonly dcsisnated as the painting stage of th inter- 
fexence. graph as claimed in the usual techniques. Dur- 
ing stage 607, the transformation process assigns to 
each lifetime interval IDjx a register number rk, in 
5 such a way that two adjacent intervals in the interfer- 
ence graph receive different register numbers. 

This operation can be iitgplemented on the basis 
of any suitable process. As a nonlimiting exajnple, it 
is indicated that a preferred process can consist: 
10 a) in choosing a peak of rainiimiin degree in. the in- 

terference graph, minimum degree being defined 
as a miniimam nvunber of adjacent peaks, and with- 
drawing it from the graph. This stage can be re- 
peated until the graph is empty. 
15 b) Each previously withdrawn peak is reintroduced 

into the interference graph in the inverse order 
of their withdrawal, the last to be removed be- 
. ing the first to be reintroduced, and succes- 
sively in the inverse order of the order of 
20 withdrawal. Thus the smallest register number 

which is different from the numbers assigned to 
all the adjacent peaks can be assigned to each 
reintroduced peak. 
Finally, by stage 602, shown in fig. 4b, the transfor- 
25 mation and reallocation process rewrites the access in- 
structions to the registers in the code of the subpro- 
gram of the relevant applet. Access to a given register 
in the corresponding lifetime interval is replaced by 
access to a different register, the number of which has 
30 been assigned during the instantiation phase, also des- 
ignated the painting phase. 

A more detailed description of an on-board data- 
processing system, making it possible to implement the 
management protocol and verification process of a pro- 
35 gram fragment or applet as claimed in the subject of 
the present invention, and of a development system of 
an applet, will now be giv n with r ferenc to fig. 6. 
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Regarding the,- coixespondihg on-boaird system with 
reference 10, it is recalled that this on-board systeja 
is a reprograinroable'-type system, including the essen- 
tial cort^onents as shown in fig. lb. The abovementioned 

5 on-board system is considered to be interconnected to a 
terminal by a serial link, the terminal itself being 
linked, for instance via a local network, if appropri- 
ate a remote network, to an applet development coitjiuter 
with reference 20. On the on-board system 10 rtms a 

10 main program vdiich reads and executes the commands 
which the terminal sends on the serial link. Addition- 
ally, the standard commands for a microprocessor card, 
such as for instance the standard commands of the ISO 
7616 protocol, can be inpl^nented, and the main program 

15 recognises two additional consnands, one for remote 
loading of an applet, and the other for selecting an 
applet which has previously been loaded onto the micro- 
processor card. 

In conformity with the subject of the present 

20 invention, the structure of the main program is imple- 
mented in such a way as to include at least one program 
module for management and verification of a downloaded 
program fragment, following the protocol for managing a 
downloaded program fragment as described above in the 

25 description with reference to fig^ 2. 

Additionally, the program module also includes a 
subprogram module to verify a downloaded program frag- 
ment, following the verification method as described 
above in the description with reference to figs. 3a to 

30 3j. 

For this purpose, the structure of the memories, 
in particular the non-writable permanent memory ROM, is 
modified in such a way as to include in particular, 
apart from the main program, a protocol management and 
35 verification module 17, as mentioned above. Finally, 
regarding the nonvolatile rewritable memory of EEPROM 
typ , this advantageously includes a directory of aP" 
plets, marked 18. making it possible to implement the 
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management protocol and verification proc 8s which are 
the subjects of the present invention. 

With reference to the same fig. 6, it is indi- 
cated that the applet development system conforming to 
5 the subject of the present invention, in fact making it 
possible to transfonn a traditional object code as men- 
tioned above in the description, and satisfying crite- 
ria Cl+C2+C'3+C'4 in the framework of the Java environ- 
ment, into a standardized object code for the same pro- 

10 grean fragment, includes, associated with a traditional 
Java compiler 21, a code transformation module, marked 
22, which proceeds to transform code into standardised 
code as claimed in the first and second inplementation 
modes described above in the description with reference 

15 to figs. 4a, 4b and 5a, 5b, It is in fact xuaderstood 
that, on the one hand, standardization of the original 
object code into a standardized object code with 
branching instruction with empty stack and into a stan- 
dardized code using typed registers, on the other hand, 

20 as mentioned previously in the description, nvakes it 
possible to satisfy verification criteria C3 and CAf 
which are inposed by the verification method which is 
the subject of the present invention - 

The code transformation module 22 is followed by 

25 a JavaCard transformer 23, which makes it possible to 
ensure transmission by a remote or local network to the 
terminal and, via the serial link, to the microproces- 
sor card 10, Thus the applet development system 20 
shown in fig. 6 makes it possible to transfoxrm the com- 

30 piled class files produced by the Java coopiler 21 from 
the Java source codes of the applet into class files 
which are equivalent, but which observe the additioxial 
constraints C3r C4 which are imposed by the management 
protocol and the verification module 17 on board the 

35 microprocessor card 10. These transform d class files 
are transformed into a downloadable applet on the card 
by the standard JavaCard transformer 23. 



Various particularly notewortliy ccsinponents of 
the set of protocol ctwnponents, methods and system^ 
which ar the subjects of the present invention will 
now be given for information only. 
S Con^ared to the v rification processes of the 

prior art as mentioned in the introduction to the de- 
scription, the verification method which is the subject 
of the present invention appears noteworthy in that it 
concentrates the verification effort on the typing 
10 properties of the operands which are essential to the 
security of execution of each applet, i.e. observing 
the type constraints associated with each instruction 
and absence of stack overflow. Other verifications do 
not appear to be essential in terms of security, in 
15 particular verification that the code correctly ini- 
tializes every register before reading it for the first 
time. On the contrary, the verification method which is 
the subject of the present invention operates iyy ini- 
tializing to zero all the registers from the virtual 
20 machine when the method is initialized, to guarantee 
that reading a non- initialized register cannot compro- 
mise the security of the card. 

Additionally, the demand imposed by the verifi- 
cation method -which is the subject of the present in- 
25 vention, as claimed in which the stack must be empty at 
each branching or branching target instruction, guaran- 
tees that the stack is in the same state, empty, after 
execution of the branching and before execution of the 
instruction to which the program has branched. This 
30 mode, of operation guarantees that the stack is in a 
consistent state, whatever the execution route which is 
followed through the code of the relevant suhprogram or 
applet. The consist^cy of the stack is thus guaranteed 
even in the presence of a branching or branching tar- 
35 g t. Contrary to the methods and systems of th prior 
art, in which it is neceseiary to conserve in random- 
acceee memory the type of the stack at each branc2hing 
target, which necessitates a quantity of ra.ndom-eccess 



memory proportional to "EipxNb, the product of the maxi- 
jraan size of execution stack which is used and th num- 
ber of branching targets in the code, th vei'ification 
method which is the subject of the present invention 
5 only needs the type of the execution stack at the tim 
of the instruction during verification, and it does not 
keep in memory the type of this stack at other points 
of the code. Consequently, the method which is the sub- 
ject of the invention is satisfied with a quantity of 
10 random-access memory proportional to but independent 
of Nb, and consequently of the length of the code of 
the subprogram or applet. 

Hhe requirement as claimed in criterion C4, as 
claimed in which a given register must be used with one 
15 and the same type throughout the code of a subprogram, 
guarantees that the abovementioned code does, not use a 
register in an inconsistent way, e.g. by writing a 
short integer to it at one point of the program and re- 
reading it as an object reference at another point of 
20 the program. 

In the verification processes which are de- 
scribed in the prior art, in particular in the previ- 
ously mentioned Java specification ^titled "The Java 
Virtual Machine Specification', edited by Tim LINDHOLM 
25 and Frank yellin, to guarantee the consistency of the 
abovementioned uses through the branching instructions, 
it is necessary to keep in random-access memory a c^jy 
of the table of register types at each branching tar- 
get. This operation necessitates a quantity of random- 
30 access memory proportional to TrXNb. where Tr designates 
the nxuiiber of registers used by the subprogram and JUb 
the nxjmber of branching targets in the code of this 
subprogram. 

On the contrary, the verification process which 
35 is the subject of the present invention operates on a 
global table of register types without keeping a copy 
at differ nt points of th code in random-access mem- 
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ory. Cpiisequently, the random-accepB mempry which is 
reqwired to implement the verification process is pro- 
portional to Tr but independent of Nb. and cons quently 
of the length of the code of the relevant subprogram. 
5 The constraint as claimed in which a given reg- 

ister is used with the same type at all points, i.e. at 
every instruction of the relevant code, simplifies ap- 
preciably and significantly the verification of subpro- 
grams. On the contrary, in the verification processes 

10 of the prior art, in the absence of such a constraint, 
the verification process must establish that the sub- 
programs observe a strict stack discipline, and imist 
verify the body of the subprograms polymorphous ly re- 
garding the type of certain registers. 

15 In conclusion^ the verification procesB which is 

the subject of the present invention, compared to the 
techniques of the prior art. makes it possible, on the 
ontf .hand, to reduce the size of the program code which 
makes it possible to carry out the verification method, 

20 and on the other hand, to reduce the consimtption of 
random-access memory during the. verification opera- 
tions, the degree of conjplexity being of the form 
0(Tp+Pr) in the case of the verification process which 
is the subject of" the present invention, instead of 

25 (0(Tp4Tr)3«l?b) for the verification process of the prior 
art, while however offering the same guarantees about 
the security of execution of the verified code. 

Finally, the process of transforming original 
traditional code into standardized code is implemented 

30 by localized trans f ©sanation of the code without trans- 
mitting additional information to the verifier compo- 
nent, i.e. the microprocessor card or on-board data- 
processing system. 

Regarding the method of reallocating registers 

35 as described in figs. 4b and 5b, this method differs 
from the Icnown methods of the prior art, as described 
in particular in US Patents 4,571,678 and 5,249,295, by 
. . the fact that! 
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the register reallocation ensures that th saw., 
register cannot be assigned to two intervale 
■with different main types, which thus gvaranteee. 
that a given register is ueed with the eaioe type 
5 throughout the code; and 

the existing register allocation algorithms, 
which are described in the abovementioned docu- 
ments, assume a fixed nuniber of registers, and 
attert5>t to roinimiae the transfers, called 
10 'spills', between registers and stack, whereas 

reallocation of registers as claimed in the sub- 
ject of the present invention operates in a 
framework where the total number of registers Is 
variable, as a consequence of which there is no 
15 purpose in carrying out transfers between regis- 

ters and stacks when a process of minimizing the 
total number of registers is carried out. 
The protocol for managing a program fragment 
downloaded onto an on-board system, and the methods of 
verifying this downloaded program fragment and of 
transforming this object code of a downloaded program 
fragment respectively, which are the subjects of the 
present invention, can of course be implemented in 
software. 

25 Therefore, the present invention also concerns a 

conputer program product which can be loaded directly 
into the internal memory of a reprogramiaable on-board 
system, this on-board system n«king it possible to 
download a program fragment consisting of an- object 

30 code, a series of instructions, executable by the mi- 
croprocessor of the on-board system by way of a virtual 
machine equipped with an execution stack and with local 
registers or variables manipulated via these instruc- 
tions po that this object code can be interpreted. The 

35 corresponding computer program product includes por- 
tions of object code to execute the protocol for manag- 
ing a program fragment downloaded onto this on-board 
system, as shown in figs. 2 and 6 described above in 



the description, when this on-board system ie intercon- 
nected to a terminal an^ this program is executed by 
the microproceesor of this on-board system by way of 
the virtual machine. 
5 The invention also concerns a cornputer program 

product which can be loaded directly into the internal 
memory of a reprogrammable on-board system, such as a 
microprocessor card with a rewritable memory, as shovai 
with reference to fig. 6. This con?puter program product 
.0 includes portions of object code to execute the stages 
of verifying a progrcgn . fragment downloaded onto this 
on-board system, as shown and described above in the 
description, with reference to figs. 3a to 3j. This 
verification is executed when this on-board system is 
L5 interconnected to a terminal and this program is exe- 
cuted by the microprocessor of this on-board system yia 
the virtual machine. 

The invention also concerns a computer program 
product; this contputer program product includes por- 
20. tions of object code to execute the stages of the 
method of transforming the object code of a program 
fragment into standardized object code for this same 
program fragment, as shown in figs. 4a, 4b. 5a, 5b and 
6^ and described above in the description. 
25 The present invention also concerns a coirputer 

; program product which is recorded on a medium which can 
be used in a reprogrammable on-board system, e.g. a mi- 
croprocessor equipped with a rewritable memory, this 
on-board system making it possible to download a pro- 
30 gram fragment consisting of an object code executable 
by this microprocessor, by way of a virtual machine 
equipped with an execution stack and local variables or 
registers manipulated via these instructions, to allow 
interpretation of this object code. Th abovementioned 
35 computer program product includes, at least, a module 
of programs which can be read by the microprocessor of 
'■. the on>board system via the virtual machine, to command 
«iecution of a pro c Oar e for managing the downloading 



of a downloaded pfograan fraginent, as shown in fig. 2 
aiid described above in th« description, a module of 
programs which can be r ad by the microprocessor via 
the virtual machine, to command execution of a proce- 
5 dure for verifying, instruction by instruction, the ob- 
ject code which makes up this program fragment, as 
shown and described in relation to figs. 3a to 3j in 
the description above, and a module of prosraroe which 
can be read by the microprocessor of this on-board sys- 

10 tem via the virtual machine, to command execution of a 
downloaded program . fragment following or in. the absence 
. of a transformation of the object code of this program 
fragment into a standardized object code for this same 
program fragment , afi shown in fig . 2 . 

15 The abovementioned conputer program product also 

includes a module of programs which can be read Toy the 
microprocessor via the virtual machine, to command in- 
hibition of execution, on the on-board system, of the 
program fragment in the case of an unsuccessful verifi- 

20 cation procedure of the abovementioned program frag- 
ment, as shown and described above in the description 
with reference to fig. 2. 
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Code of method 
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aload 0 








sconst 3 
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sfeload 
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Pointer to instruction 
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■ TABLE 2 

. gseucLo-rCode. of verifier module 
PSEODO-CODB OF VERIFIER MODULE 

5 

Oldbd variables used: 

Tr nuiDbex of registers declared by current method 

r maximusiisitcofstackdeclaiedbycuiyemmet^ 
tr[TrJ table of register types (402 in fig. 4) 

10 <P/Tp/ sta<*typfc(403infig,4) 

pp stack pointer (404 in fig. 4) 

chi flag indicating whether rr has changed 

Initialirepp-^O 

britidi2crpIO]...r/7[n.l3fn?n)typesofrtargunu»t»ofmcft • ~ • 

15 Initialize ip[n].-apirr-l] to J- 
Initializec/i^totrue 
While cAg is true: 

Reset cAf to false 

Position on first instruction of mediod 
20 While end of meOiod is not reached: 

If current instfwtion is target of a branching instruction: 

lfpp4 0, verification fails 
. If current insnruction is .taiget of a sobroudnecaU: 

If previous instruction continues in sequence^ failure 
25 Take frfOl^r-eiaddr and 

If cunwt instruction is an exception handler of dass G 

If previous instruction condnues in sequence, failute 

Do JJpIO]^ C and pp^\ 
V current instruction is a target of different kinds: 
30 Verificadon fidls 

Determine types o; ... a, of arguments of instniedon 
If < n, fiuluie (stack overflow) 
For 1=1, 

If tplpp-n-i-J] is not subtype of ftilwie 
35 Dopp<^ppin 

Determine types n, r,, of results of insiniction 
lipp^n^p, failure (stack overflow) 
For I = 1, „^ m, do ipt/H-f-l] 7 r, 
Do pp^pp^m 

4 0 If current Insttuctipn is a write to a register r: 
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Detennine type I of value written 10 Tccoid 

Do tf[r] Haiyer bound (u trlr]) 
If iKO ^ cihanged, do c^gf* brtte 

If cuTrent instruction is a farancMng: 
If fp4'0. verificatiaD fftiline 

Advance to next instruction 
Rfitiim verification success code 



TABLE T3 



Static sJionO acth(5hort Q table ) 
{ 

short □ result « null; 
ii ( table length >» 2) result = table; 
return table 
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TABIiE T4 



First jteratfon on methDd code: 
Method code , 


0 ; 






1 : 
• 







2: 







3: 






4 : 


sconsx 3 




I: 


il.scaplx 9 - 




7 I 


^oud 0 




8: 


d.axor« 1 




9 ; 






10* 


aretm 




Second iteration on method cc 


0: 


acowt^mll 




1 : 






3: 


alcad 0 




3 ! 






< : 


s coast 2 




bl 






T: 


aload 0 




8: 


aster* 1 




6 : 


&Ioad 1 




10: 


arctvni 





Table of register types 



stack type 
□ I 

3 



I 



»tiortU|xt; <UrtUi 



|.rl: shcrxLLl | 

■ rrO! 8iicrtU|rl: »hprt'LQ r mil I 

^ |rO: •h^rtUlrl; aii crtlTi | 

> |rO: gbortlJ 

JroT gbcrr Uir^: anoigffl I 



* lrOi ahcrt 
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TABLE. T5 



(a) Vio/a<ion cotustraifOs on qrguments cf an instruction: 

\ lO; Object! ]■ 



0 : 


£load 0 


1 : 


sconst 1 


2 : 




3 : 


axetvrs 



063 



Error stack type does not 
correspond to what instruction 
expects (short, short) 



(b) Inconsistent use of a register: 



sload 0 




ijfeq 6 - 


• * • ■ *k* • • • 




«5Xoxe 0 


• • • • tit mm m 


2lD&d 0 





\ rO: sbort ( 


1 




[ rO: Bliort j 


1 






1 




{ rO: uikOtX i 


1 


vail 1 


1 rO.. T ( 


1 




1 r6: t ■, 


r 





Error, stack type does not correspond 
to what Instruction expects (Object) 



(c) Branchings Introducing inconsistencies ai stack level: 



0: 


Elcsd 0 


1 : 


if«S 8 - 


4: 


scesst 1 


5 : 




8 : 




9: 


&X«ltlZll 





short i 


1 


1 rtfT 


sbcrt i 




.| r6: 




1 



" < rOt chert i I ahcrr" 



Error stack not emply art branching point 



(d) Stackpverflow within a loop: 



0: 


sloii 0 


1 : 


iieq 31 ^ 


4 : 


scoa$t 1 


5 : 


sitkt 0 -J 


8: 


goto 0 "4 


11 ; 


xettjrn [ 



* l rO; ahort | | 

r- H rO; <hort | f shore | 

-" I rO: 8hort ( | 

ihcrt J } khcrtl 



Error stack not empty at branching point 



TABLE T6 



(a) /iifria/ co^fe of method^ annotaied by types of registers and cf stack: 

\ rOt Objtcti I 



0 : 


aload 0 


1 : 


iin-all 8 - 


4 : 


icotust 1 


9 • 




S: 


icca^t 0 


9; 


i&tg 


10: 


istore 0 


11 : 


iJoad 0 


12 : 





• I rO: ObjecTI 1 iat | 
• I rO; Objtct | ) 



' I rOt Obj^cTI I i&X I 



rO: int 



I 



TABLE T7 

(b) Method code qfier standardvuition. of stack at branching-5 

• \ xQi Object { 



9: 



0: 


aload 0 




1 : 


iinull 8 - 




< : 


iCOASt 1 




4' ; 


istor« 1 


«•■••] 


5: 


goto 8" - 


* • • • jf ■ • 


8 : 


i const 0 


*»**«|««« 


8': 


istori 1 


• • • • y» • • • 


8-: 


ilcad 1 




9: 


iseg 




10: 


istcr* 0 




n-' 


iloftd 0 




12: 


iretura 





rl: J. 



\ rO: Object j 



rl: 1 



■ I rO; Object | rl: T 



' ( rO; Object | riTT" 



• } rO; Object | rlt int 



rO: Object | zit iat 



• ' I rO: Object | rl; I 



■ f rO! Object I rl! lat 



' \ vOi Object I rl; iat 



• I rOt Object j rl; iat 



rO; int j rl: int 



'. \ rO; int \ rlt iat 



Int I 



int I 



anx 
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TABLE T8 

ic):Mphod code after realloecaion of registers: 



0: 


aload 0 


1 ; 


ifnull 8 ~ 


4 ; 


i const 1 


4' ; 


istore 1 


5 : 


goto 8'* — 


8 : 




8' ; 




8" : 


iload 1 


9: 


iBeg 


10: 


1st ore 1 


n : 


iload 1 


12; 





•1 rO: Object 


rl 


; 1 


1 




•| rO: Obj«et | 


rl 


: JL 




-| rO: Object | 


rl 


: 1 


. 1 


♦1 tO: Object 1 


rl 


: J. 




•j rO: Object | 


rl: 
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-j tp: Obj«ci j 


rl: 


inx 




-| rO: Object | 


rl 


i ± 






•( rO: Object J 


rl: 


int 
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■I TO: Object | 


rl: 


int 
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1 rO; Object | 


rl: 


Oilt 
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LxO: Object 1 


XI: 


i&t 


1 
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lAt 



int I 



lat" 



I tO: Object | rl; int \ \ iat \ 



TABLE T9 

(t^.Branching target, previous instruction not continuing in sequence: 
Branching Brandling 



noh-seq. instr. 



stack state 



Standafcf^'on 



non-eeq. instr. 



1m4 ri 



mstraction t 



-stack 8t9t6 

I 



TABLE TIP 

(hi Branching targei, previous insiruction continuing in sequence: 
Branchinfl Branchinfl 



seq. instr. 



iastTuction i 



EI3 



Standardization 



seq. instr. 



store T2 



store ti 



loaid Ti 



load 



instractkmi 



5 TABLE Til 

(c) Unconditional branching without arguments: 

Stendarcfization 



goto 



Target 



Target 









store 


goto 


^ — 





foTT] 

l£} 
I 



TABLE T12 • 
10 (c) Conditional branching with one argument: 



Target 



Standardization 



□an 



Target 



stors rs 
stors n 

iftq 
load n 
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i. CLAIMS 

1. A prptocol for managing a program fragment 
ciovhlpaded onto a reprogrammable on-board eystem, eueh 
ae a microprocessor card equipped with a rewritable 
memory, said program fragment consisting of an object 
code, a series of instructions, executable by the mi- 
croprocessor of the on-board eystCTi by way of a virtual 
machine equipped with an execution stack and with local 
variables or registers manipulated via these instruc- 
tions and making it possible to intenpret this object 
code, said on-board system being interconnected to a 
terminal, characterized in that this protocol consists 
at least f at the level of said on-board sysitem: 

a) in detecting a command for downloading of this 
program fragment:; and, on a positive response to 
this stage consisting in detecting a downloading 
command, 

b) in reading the object code constituting this 
program fragment and in ten^jorarily storing this 
object code; 

c) in subjecting the whole of the object code 
stored teirqpprarily in memory to a verification 
process, instruction by instruction, this veri- 
fication process consisting at least in a stage 
of initializing the type stack and the table of 
register types representing the state of said 
virtual machine at the start of the execution of 
the temporarily stored object code and in a suc- 
cession of stages of verification. Instruction 
by instruction, by discerning the existence, for 
each current instruction, of a target, branch- 
ing-instruction target, target of an exception- 
handler call, or target of a subroutine call, 
and in a verification and an updating of the ef- 
fect of said current instruction on the type 
stack and on the table of register types, and, 
in the event of a successful verification of 
said object coCb, 



d). in recording the;\ dovTQloadea program fragment in 

a directory of available program fragments, and* 
in the vent of an unsuccefieful verification of 
said object code, 
5 e) in inhibiting execution, on said on-board sys- 

tern, of said program fragment. 

2< Thq protocol as claimed in claim 1, charac- 
terized in that said stage e) of inhibiting the execu- 
tion consists: 

10 f ) in deleting the momentarily recorded program 

fragment, when omitting to record the latter in 
said directory of available program fragments, 
and 

g) in sending an error code to said reader. 

15 3. The protocol as claimed in claim 1 or 2, char- 

acterized in that, on a negative response to said stage 
a) consisting in detecting a downloading command, thie 
consists: 

b') in detecting a command to select an available 

20 program fragment from a directory of program 

fragments; and, on a positive response to this 
stage, consisting in detecting a command to se- 
lect an available program fragment;- 
c') in calling said selected available program frag- 

25 ment; 

dM in executing said called available program frag- 
ment via the virtual machine, with no dynamic . 
verification of variable types, access rights to 
the objects which are manipulated by the called 

30 available program fragment, or overflow of the 

execution stack when each instruction is exe- 
cuted, and, on a negative response to this stage 
consisting in detecting a command to delect an 
available program fragment, 

35 e') in proceeding to process the standard commands 
of the on-board system. 

4. A method ■ of v rifying a program fragment 
downloaded onto a r programmable on-board system, such 



as a ipicr ©processor ca^xd equipped with a rewritable 
m^pry, said program fragment consisting of . an object 
code, and including at least one subprogram, a seri s of 
instructions, by the microprocessor of the on-board 
system by way of a virtual machin equipped with an 
execution stack and with operand registers manipulated 
by these instructions, and making it possible to inter- 
pret this object code, said on-board system being in- 
terconnected to a reader, characterized in that said 
method, following the detection of a downloading com- 
mand and the storage of said object code constituting 
this program fragment in said rewritable memory, con- 
sists, for each subprogram: 

o) in carrying out a stage of initializing the type 

stack and the table of register types by data 
representing the state of the virtual machine at 
the start of the execution of the temporarily 
stored object code; 

P) in carrying out a verification of said temporar- 

ily stored object code instruction by instruc- 
tion, by discerning the existence, for each -cur- 
rent instruction, of a target, a branching- 
instruction target, a target of an exception- 
handler call or a target of a sxibroutine call; . 
y) in carrying out a verification and an updating 

of the effect of said current instruction on the 
data types of said type stack and of said table 
of register types, on the basis of the existence 
of a branching-instruction target, of a target 
of a subroutine call or of a target of an excep- 
tion-handler call, said verification being suc- 
cessful when the table of register types is not 
modified in the course of a verification of all 
the instructions, and the verification process 
being carried out Instruction by instruction un- 
til the table of register typ s is stable, with 



no modification present, the v riff cation proc- 
ess being interrupted otherwise. 

5. The verification method as tlaimed in claim" 
4, characterized in that the variable types which are 

5 manipulated during the verification process includ at 
least : 

class identifiers corresponding to object 
classes which are defined in the program frag- 
ment; 

10 - numeric variable types including at least a type 

short y an integer coded on p bits, and a type 
retaddr for the return address of a jun© in- 
struction JSR; . . 
a type null relating to references of null ob*- 

15 jects; 

a type object relating to objects; 
• - a first specific type X# representing the in- 

tersection of all the types and corresponding to 
the value 0, nil ; 

20 r a second specific type T, r^resenting the union 

of all the types and corresponding to any type 
of value. 

6. Method as claimed in claim 5, characterized 
in that all said variable types verify a sxabtyping re- 

25 lation: 

ob j ect £ T; 

short , retaddr g T; 

ienull/ short y retaddr . 

7. The method as claimed in one of claims 4 to 
30 6, characterized in that when said current instruction 

is the target of a branching instruction, said verifi- 
cation method consists in verifying that the type stack 
is empty, the verification process being continued for 
the following instruction in the case of a positive 
35 verification, and the. verification process failing and 
the program fragment being rejected othervis « 



8. The method asi. claimed in one of claims 4 to 
7^ GharacterizeiEl . in that when said current instruction 
is the target of a subroutine call, said verification 
process verifies that the previous instruction is an 
5 unconditional branching, a subroutine return or a rais- 
ing of an exception, said verification process, in the 
case of a positive verification, proceeding to reupdate 
the stack of variable types by an entity of retaddr 
type, the return address of the subroutine, and the 

10 verification process failing and the program fragment 
being rejected otherwise. 

9« The method as claimed in one of claims 4 to 
8, characterized in that when the currgat instruction 
is the target of an exception handler, said verifies- 

15 tion process verifies that the previous instruction is 
an xmconditional branching, a subroutine return or a 
raising of an exception, said verification process, in 
the case of a positive verification, proceeding to re- 
update the type stack by entering the exception type, 

20 and the verification process failing and the program 
fragment being rejected otherwise. 

10- The method as claimed in one of claims 4 to 
9i characterized in that when the current instruction 
is. the target of multiple inconpatible branchings, the 

25 verification process fails and the program fragment is 
rejected* 

11. The method as claimed in one of claims 4 to 
10, characterized in that when the current instruction 
is not the target of any branching, the verification 

30 process continues 1^ passing to an update of the type 
stack. 

12. !l^e method as claimed in one of claims 4 to 
11^ characterised in that the stage of verification of 
the effect of the current instruction on th type stack 

35 includes, at 1 ast: 

a stage of v rifying that the typ execution 
stack includes at least as inany entries as the 
current instruction includep operands; 
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a Stage of nanetacking and of verifying that the 
types of the. entries at the top of the stack are 
jsubtypes of the types of the op rands of the qp- 
erands of this instruction; 

a stage of verifying the existenc of a suffi- 
cient memory space on the type stack to proceed 
to stack the results of the current instruction; 
a stage of stacking on the stack data types 
which are assigned to these results. 

13. *he method as claimed in claim 12, charac- 
terized in that when the current instruction is an in- 
struction to read a register of address n, the verifi- 
cation process consists: ^ w. 

in verifying the data type of the result of this 
reading^ by reading the entry n in the table of 
register types; 

in determining the effect of the current in- 
struction on the type stack by unstacking the 
entries of the stack corresponding to the oper- 
ands of this curr;ent instruction and by stacking 
the data typ? of this result:. 

14. The method as claimed in claim 12, charac- 
terized in that when the current instruction is an in- 
struction to write to a register of address m, the 
verification process consists: 

in determining the effect of the current in- 
struction on the type stack amd the type t of 
the operand which is written dLn this register of 
address m; 

in replacing the type entry of the table of reg- 
ister types at address m by the type immediately 
above the previously stored type and above the 
type t of the operand which is written in this 
register of address m. 
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.15. A method of transforming, an object code of a 
program fragment, in which the operands of ach in- 
struction belong to the data types manipulated by this 
instruction, the execution stack does not exhibit any 
overflow phenomenon, for each branching instruction, 
the type of the stack variables at this branching is 
the same as at the targets of this branching, into a 
standardized object code for this sane program frag- 
ment, in which the operands of each Instruction belong 
to the data types manipulated by this instruction, the 
execution stack does not exhibit any overflow phenome- 
non, the execution stack is eaupty at each branching in- 
struction and at each branching- target instruction, 
characterized in that this method consists, for all the 
instructions of said object code: 

in annotating each current instruction with the 
data type of the stack before and after execu- 
tion of this instruction, the annotation data 
being calculated by means of an analysis of the 
data stream relating to this instruction; 
in detecting, within said instructions and 
within each current instruction, the existence 
of branchings, or respectively of branching- 
targets, for which said execution stack is not 
einpty, the detection operation being carried out 
on the basis of the annotation data of the type 
of stack variables allocated to each current in- 
struction, and In the presence of detection of a 
non-eitpty execution stack, 

in inserting instructions to transfer stack 
variables on either side of these branchings or 
of these branching targets, respectively in or- 
der to empty the contents of the execution stack 
into temporary registers before this branching 
and to r establish the execution stack from said 
tenflporary registers after this branching, and in 
not inserting any transfer instruction other- 
wise, making -it possible to obtaiu a standard- 
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iz d object code for this sajne program fragment, 
in which th execution stack is empty at each 
branching instruction and at each branching- 
target instruction I in the absence of any modi- 
5 fication to the xecution of said program frag- 

ment. 

16. A method of transfontdng an object code of a 
program fragment, in which the operands of each in- 
struction belong to the data types manipulated by this 

10 instruction, and an operand of given type written into 
a register by an instruction of this object code is re- 
read from this same register by another instruction of 
this object code with the same given data, type, into a 
standardized object code for this same program frag- 
15 ment, in which the operands of each instruction belong 
to the data types manipulated by this instruction, the 
same data type being allocated to the same register 
throughout said standardized object code, characterized 
in that this method consists, for all the instructions 
20 of said object code: 

in annotating each current instruction with the- 
data type of the registers before and after exe- 
cution of this instruction, the annotation data 
being calculated by means of an analysis of the 
25 data stream relating to this instruction; 

in carrying out a reallocation of the registers^ 
by detecting the original registers employed 
with different types, by dividing these original 
registers into separate standardized registers, 
30 one standardized register for each data type 

used, and reupdating the instructions which ma- 
nipulate the operands which use said standard-* 
ized registers. 

17. The method as claimed in claim 15, charac-- 
35 terized in that the stag .consisting in detecting'^ 

within said instaructions and within each current in- 
struction, th existence of branchings^ or respectiv ly 
of branching targets, for \:hich th ex cution stack is 
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not;- einpty, consists, foliowing detection of each corr - 

eponding instruction of rank i: . 

in associating with, each instruction of rank i a 
set of n w r gieters, one new register being as- 
sociated with each stack variable which is ac- 
tive at this instruction; 

in examining each detected instruction of rank i 
and in discerning the existence of a branching 
target or branching, respectively, and, in the 
case where the instruction of rank i is a 
branching target and that the execution stack at 
this instruction is not empty, 

• for every preceding instruction, of rank 
i-1, consisting of a branching, a rais- 
ing of an exception or a program return, 
the detected instruction of rank i being 
accessible only by a branching, 

•• in inserting a set of load instructions 

load to load from the set of new regis- 
ters before said, detected instruction of 
rank i, with redirection of all branch- 
ings to the detected instruction of" rank 
i to the first inserted load instruction 
load ? and 

• for every preceding instruction, of rank 
i-1, continuing in sequence, the de- 
tected instruction of rank i being ac- 
cessible simultaneously by a branching 
and from the preceding instruction of 
rank i-1, 

in inserting a set of backup instruc- 
tions store to back up to the set of new 
registers before the det ct d instruc- 
tion of rank i, and . a set of load in- 
structions load to load from this set of. 
new regist rs, with redirection of . all 
the branchings to the detected inntruc- 
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tion of rank i to t±ie first inserted 
load instruction loadi and, in the cas 
where said detected instruction of rank 
i ie a branching to a given instructioa, 
5 • for every detected instruction of rank 1 

consisting of an unconditional branch- 
ing, 

in Inserting, before the detected in- 
struction of rank i, ntultiple backup in- 
10 ■ structions store , a bac3cup instruction 

being associated with each new register; 
and 

• for every detected irifetJanictioji of rank i 

consisting of a conditional branching, 
15 and for a nuniber in > 0 of operands ma- 

nipulated by this conditional branching 
instruction, 

in inserting, before this detected in- 
struction of rank i, a permutation in- 

20 struct ion, swap-x , at the top of the 

execution stack of the xn operands of the 
detected instruction of rank i and the n 
following values, this permutation op- 
eration making it possible to collect at 

25 the top of the execution stack the n 

values to be backed up in the set of new 
registers, and 

in inserting, before the instruction of 
rank i, a set of baclcup instructions 
30 store to back up to the set of new reg- 

isters, and 

in inserting, after the det cted in- 
struction of rank i, a set of load in- 
structions load to load from the set of 
35 new registers. 

18. The method as claimed in claim 16, charac- 
teriz d in that th stage consisting in reallocating 
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::: reikis ters by detecting the original refii.sters «nploy d 
iwith different types conei 

- . in d termining the lifetime intervals of each 

register; 

in determining the main data type of each life- 
time interval, the main data type oi a lifetime 
interval i for a regieter r being defined by the 
upper bound of the data types stored in this 
register r by the backup instructions store be- 
longing to the lifetime interval j; 
in establishing an interference graph between 
the lifetime intervals, this interference graph 
consisting of a non-oriented graph of . which each 
peak consiats of a lifetime interval, and of 
which the arcs between two peaks ji and 3*2 exist 
if a peak contains a backup instruction ad- 
dressed to the register of the other peak or 
vice versa; 

- in translating the uniqueness of a data type 
which is allocated to each register in the in- 
terference graph, by adding arcs between all 
pairs of peaks of the . interference graph while 
two peaks of a pair of peaks do not have the 
same associated main data type; 

in carrying out an instantiation of the inter- 
ference graph, by assigning to each lifetime in- 
terval a register number, in such a way that 
different register numbers are assigned to two 
adjacent life intervals in the interference 
graph. 

19. An on-board system which can be reprogrammed 
by downloading program fragments, including at least 
one microprocessor, one random-access memory, one in- 
put/output mpdule, one electrically reprogrammable non- 
volatile memory and one permanent memory, in which ar 
install d a main piogram and a virtual machine which 
makias it possible to execute the main program and at 
least on prograxu fragment using said microprocessor,- 
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che^^cterized in that said on-boar(^ system includes at 
least one program module to Tnanag and verify a down- 
load d program fragment, eaid management: and verifica-' 
tion program module being installed in the permanent 
5 memory. 

20. An on-board system which can be r^rogrammed 
by downloading program fragments , including at least 
one microprocessor, one random-access memory, one in- 
put/output module, one electrically reprogrammable -non- 

iO volatile memory and one permanent memory, in which are 
installed a main program and a virtual machine which 
makes it possible to execute the main program and at 
least one program fragment using said. ^microprocessor, 
characterized in that said on-board system includes at 

15 least one program module to manage and verify a down- 
loaded program fragment in accordance with the protocol 
for managing a downloaded program fragment as claimed 
in one of claims 1 to 3, said management and verifica- 
tion program module being installed, in the permanent 

20 memory. 

21. The on-board system as claimed in claim 20, 
characterized in that it includes at least one subpro-. 
gram module to verify a downloaded program fragment, in 
accordance with the verification process as claimed in 

25 one of claims 4 to 14. 

22. A method of transforming an object code of a 
program fragment, in which the operands of each in-- 
struction belong to the data types manipulated by this 
instruction, the execution stack does not exhibit any 

30 overflow phenomenon, for each branching instruction, 
the type of stack variables at this branching is the 
same as at the targets of this branching, and an oper- 
and of given type written to a register by an instruc- 
tion of this object cod is reread from this same reg- 

35 ister by another instruction of this object cod with • 
the same given data type, into a standardized obj ct 
code for this same program fragment r in which the oper- • 
anCs of each instruction belong to the data types ma- 
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nlpulated by this instruction^ the execution stack does 
not exhibit overflow phfenomenon, the execution stack is 
ernpty-at each branching instruction and at each branch- 
ing-target instruction^ the same data type being as- 
5 signed to the same register throughout said standard- 
ized object code^ characterized in that said conversion 
system includes, at least* installed in the working 
memory of a development computer or workstation, a pro- 
gram module to transform this object code into a stan- 
10 dardized object code in accordance with the method as 
clj^imed in one of claims 15 to 18, making it possible 
to generate a standardized object code for said program 
fragment, satisfying the criteria for verifying this 
downloaded program fragment. 
15 23. A computer program product which can be 

loaded directly into the internal memory of a repro- 
grammable on-board system, such as a microprocessor 
card equipped with a rewritable memory/ this on^board 
system making it possible to download a program frag- 
.20 ment consisting of an object code, a series of instruc- 
tions, executable by the microprocessor of the on-board 
system by way of a virtual machine equipped with an 
execution stack and with local variables or registers 
manipulated via these instriictions and making it possl- 
25 ble to interpret this object code, this con5>uter pro- 
gram product including portions of object code to exe- 
cute the protocol for managing a downloaded program 
fragment on this on-board system as claimed in one of 
claims 1 to 3, when this on-board system is intercon- 
30 nected to a terminal and this program is executed by 
the microprocessor of this on-board system by way of 
said virt\ial machine. 

24, A conflputer program product which can be 
load d directly into the internal memory of a repro-' 
35 grammable on-board system, such as . a microprocessor • 
card equipped with a rewritable memory, this on-board 
system making it possible to download a program frag- 
ment consisting of an objoct code, a seri s of ins true- 



wo 01/14958 - 71 - PCT/FROO/02349 

•I 

. . tlona^ execrutaidl<5 by the microproc eeor of th on-board 
system by \/ay; of e^; virtual machine equipped with aani 
execution stack and with operand registers manipulated 
via th se instructions and making it possibl to inter- 
5 pret thiSx object code, this coinputer program product 
including portions of object code to execute the stages 
of verifying a program fragment dot«nloaded onto this 
on-board system as claimed in one of claims 4 to 14, 
when this on-board system is intercoxmected to a termi- 

10 nal and this program is executed hy the microprocessor 
of this on-board system hy way of said virtual machine. 

• 25 • A computer program product including por- 
tions of object code to execute stages of the method of 
transforming an object code of a downloaded program 

15 fragment into a standardized object code for this same 
program fragment as claimed in one of claims 15 to 18. 

26- A cornputer program product which is recorded 
on a medium which can be used in a reprogrammable on-- 
board system, such as a microprocessor card equipped 

2b with . a rewritable memory, this on-board system making 
it possible to download a program fragment consisting 
of an object code, a series of instructions # executable 
by the microprocessor of the on-board system hy way of 
a virtual machine equipped with an execution stack and 

25 with local variables or registers manipulated via these 
instructions and making it possible to interpret this 
object code, this coj^puter program product including, 
at least: 

program resources which can be read by the mi- 
30 crpprocessor of this on-*board system via said 

virtual machine, to command execution of a pro- 
cedure for managing the downloading of a down- 
loaded program fragment; 

program resources which can be read by the mi- 
3.5 croproceesor of this on-board system via said 

virtual machin , to command execution of a pro- 
cedur for verifying, instruction by instruc- 



tion, the obj^Bct code which makes up said pro- 
gram, fragmient; 

program resources which can be read by the mi- 
croprocesBor of this on-board system via said 
5 virtual machine, to connnand xecution of a down- 

loaded program fragment following or in the ab- 
sence of a conversion of the object code of this 
program fragment into a standardized object code 
for this same program fragment, 
io 27. The computer program product as claimed in 

claim 26# additionally including program resources 
which can be read by the microprocessor of this on- 
board system via said virtual machine, to command inhi- 
bition of execution, on said on-board system, of said 
15 program fragment in the case of an unsuccessful verifi- 
cation, procedure of this program fragment. 
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